Текст книги "Введение в управление проектами внедрения ERP-систем"

1.4.Затраты на владение системой (стоимость эксплуатации)

Чтобы закрыть вопрос о понятии «ERP» и перейти наконец-то к основной теме проектов внедрения, нужно рассмотреть еще немаловажные финансовые вопросы затрат на владение системой такого класса.

TCO (англ. Total Cost of Ownership) – это совокупная стоимость владения, общая величина целевых затрат, которые вынужден нести владелец с момента начала владения до момента выхода из состояния владения.

Для начала нужно убрать заблуждение, которое реально встречается в тех компаниях, что хотят перейти на ERP-систему: «Вот мы сейчас все это внедрим (пусть и дорого) – и будет нам хорошо, одна сплошная прибыль и окупаемость затрат на внедрение».

Если понимание, что сама система имеет цену, а работы по ее пусконаладке как услуги тоже что-то стоят, есть, то вот что с этой системой происходит дальше – понимания часто нет.

Но бывает и такое, совсем парадоксальное: автор лично был свидетелем ситуации, когда компания покупала систему для автоматизации бизнес-процессов документооборота и управления финансами и эта система лежала в красивой коробке почти год. При этом по договору о продаже системы были какие-то часы на демонстрацию ее работы, но на компьютере, где это показывали, переустановили операционную систему, а сотрудник, кому показывали, уволился. И на балансе бухучета числился этот «актив», по сути являясь балластом. Бизнес-процессы так и шли через бумажки, стикеры (кому отдать, что сделать) и электронную почту.

Важно понимать, что делать с приобретаемой КИС (при внедрении) и потом (при использовании). Собственно, об этом в книге речь и идет: цель – убрать такие пробелы в понимании, в том числе у тех, кому внедряют ERP-систему.

Как и из чего формируется стоимость проекта внедрения, будет подробно рассматриваться в главе «Как оценить срок и бюджет проекта». Но там рассмотрение будет со стороны управления проектами, то есть для внедренцев. А для потребителя что?

Прикинем состав затрат на приобретение и запуск системы в работу:

● стоимость «коробочной» версии ERP;

● стоимость лицензий на одно рабочее место;

● стоимость лицензий на сервер;

● стоимость сервера системы управления базами данных (СУБД). Это ПО от сторонних поставщиков. Там своя лицензионная политика: на пользователей, на ядра процессора;

● стоимость аппаратного сервера (нескольких серверов), куда все будет устанавливаться. Возможно, нужен не один, а несколько серверов с объединением в кластер, либо настройки идут через виртуальные машины на очень мощном едином сервере;

● серверные операционные системы для серверов;

● системы резервного копирования;

● услуги по пусконаладке серверов и встраиванию их в сетевую инфраструктуру компании;

● квадратные метры помещения для размещения аппаратуры, вентиляция, аккумуляторные блоки для бесперебойной работы серверов в режиме 24/7;

● затраты на организацию системы удаленного доступа к системе;

● консалтинговые услуги проекта внедрения ERP-системы;

● зарплата сотрудников, задействованных частично или полностью на проекте внедрения со стороны заказчика (включая сотрудников, отвлекаемых от основной работы на время обучения новой системе);

● обновление или приобретение новых компьютеров и/или мониторов для рабочих мест сотрудников – будущих пользователей. Это часто не учитывается, а между тем текущий парк персональных компьютеров может не позволить комфортно работать в новой системе (скорость работы, разрешение экрана). А если пользователей много, то и бюджет обновления будет значительным.

Сегодня ERP-системы поставляются в электронном формате, документация также доступна через Интернет, что позволяет поставщику поддерживать документацию и систему всегда в актуальном состоянии, регулярно публиковать обновления для системы.

Но некоторые покупатели, которые ожидают что-то материальное после приобретения ERP-системы, что можно подержать в руках, могут восклицать: «Где все? Мы же заплатили деньги, где система? А нам какую-то ссылку на сайт прислали!»

Рис. 1.4. Коробка с системой и документацией 1С: ERP

Для таких клиентов фирма «1С» дополнительно к электронной поставке может предоставить физическую картонную коробку – там диски и документация. Коробка с 1C: ERP весит очень прилично и, прямо скажем, «внушает». Это снимает дискомфорт от нематериальной сути приобретаемой ERP-системы.

Рассмотрим отдельно важную статью расходов – на системы резервного копирования.

Очень хочется прокомментировать ситуацию с резервным копированием известной в ИТ-кругах поговоркой: «Есть те, кто еще не делает резервные копии, и есть те, кто уже делает!» Совет: не нужно дожидаться этого «уже»!

Это важный пункт в перечне дел для внедрения, и нужно сразу настраивать создание резервных копий базы данных, т. к. ценность ее перекроет все затраты. Частота бэкапов должна быть разумной, как и глубина хранения версий. Даже откат базы на один день назад – это потеря сотен человеко-часов работы сотрудников и потерянные полдня-день на восстановление. А неделя, а вся база за годы?

Расходы на покупку сервера: как правило, имеющиеся на предприятии серверные ресурсы уже распределены между существующими задачами, и дополнительная нагрузка способна негативно сказаться на новых и старых задачах. Оборудование просто не потянет. А серверы стоят прилично. На этапе проектирования следует предусмотреть модернизацию или приобретение серверного и сетевого оборудования под планируемые объемы данных и нагрузку.

Как видно из перечня затрат на приобретение и внедрение ERP, это далеко не одна-две строки. Аппаратное обеспечение для серьезного объема данных в такой системе тоже будет иметь стоимость. Все это должно работать и после запуска в промышленную эксплуатацию.

Вот мы и переходим к стоимости владения. Что в нее входит?

● Техническое обслуживание серверов (затраты на ИТ-специалиста в штате или приглашаемого на время).

● Подписка на сопровождение и обновления для КИС (для западных ERP-систем это значительная статья расходов, т. к. стоимость подписки может быть 20–30 % от стоимости всех лицензий на КИС в год).

● Затраты на службу внутренней поддержки пользователей или внешних специалистов, привлекаемых для решения возникающих в работе вопросов и небольших доработок (включая затраты на командировки, если это требуется, например, для обучения новых сотрудников в филиалах).

● Регулярные обновления системы на новые версии, содержащие новый функционал, исправление ошибок и, главное, поддержка изменений законодательства (для систем автоматизации бухгалтерского и налогового учета). Нужно учесть, что чем больше доработок и изменений было внесено в «коробочную» версию ERP при внедрении, тем дороже и сложнее происходит такое обновление.

● Обновление (upgrade) аппаратуры серверов для масштабирования при росте нагрузки или поломках/устаревании/износе.

● Дополнительные регулярные расходы на возникшую из-за появления ERP инфраструктуру в компании.

Если все эти затраты оцифровать и составить бюджет проекта внедрения и месячной (или годовой) стоимости эксплуатации, то станет понятно еще одно отличие ERP от учетных бухгалтерских систем – это еще и прилично дороже. Ведь бухгалтерская программа для небольшой компании и одного бухгалтера может работать на обычном ПК, без серверов и не требует дорогого консалтинга на внедрение. Курсы или самостоятельное изучение по книжкам вполне реалистичны для запуска бухгалтерского учета.

Можно ли как-то оптимизировать затраты на ERP-систему? Можно, если посмотреть в сторону облачных решений и SaaS (Software as a Service) предложений аренды аппаратного и программного обеспечения.

Рассмотрим аспект использования ERP-системы в облаках.

Облака, cloud-сервисы, облачные технологии – модель обеспечения удобного сетевого доступа по требованию к некоторому общему фонду конфигурируемых аппаратных и/или программных ресурсов.

В такой облачной модели нет затрат на ERP-систему:

– Разовых:

● приобретение аппаратных серверов;

● услуги по пусконаладке аппаратуры серверов и серверной комнаты;

● приобретение лицензий на все ПО (сервер приложений, само ERP-решение, лицензии на пользователей, серверные операционные системы);

● резервное копирование;

● обновление (upgrade) серверов по необходимости (поломки, устаревание) или для масштабирования (рост компании и числа пользователей).

– Регулярных:

● оплата ИТ-специалистов по обслуживанию серверов;

● содержание серверной комнаты;

● годовая подписка поддержки на обновление ПО;

● процесс обновления ERP-системы на актуальную версию (тут не все просто, об этом ниже).

В свою очередь, появляются новые регулярные траты – месячная подписка на обслуживание по каждому пользователю или пакетно.

Экономия на стоимости разовых затрат будет существенной. Причем временная экономия тоже: не нужно ждать поставки и настройки оборудования. Оплата месячного обслуживания, даже если будет в итоге больше, чем затраты на поддержку работающей системы своими силами, все же распределена по времени, и бизнесу не нужно вынимать из оборота часть средств в момент запуска системы. Но, главное, не нужно организовывать внутри компании непрофильную для ее деятельности ИТ-службу по поддержке всего серверного аппаратного и программного обеспечения.

Рис. 1.5. Схема облачного сервиса

В случае проекта внедрения можно на первых этапах без приобретения дорогостоящего оборудования и самой ERP-системы «попробовать», как это будет на практике: готова ли компания к проекту внедрения вообще и подходит эта конкретная система бизнесу. Нужно отметить, что облачные сервисы возможны нескольких вариантов (и все они могут быть сопряжены с использованием ERP-системы):

– IaaS (инфраструктура как сервис) – клиент использует физические или виртуальные серверы, дисковые хранилища и прочее оборудование оператора облака для конфигурирования своей ИТ-инфраструктуры.

● Клиент не может определять, как указанные блоки физически соединены между собой, но может строить из них логические конфигурации в рамках ограничений, определенных оператором.

● Оператор несет ответственность за функционирование аппаратных блоков и их связь между собой.

● Обслуживанием ОС и программного обеспечения (включая ERP) занимается клиент.

● Резервное копирование СУБД и приложений настраивает и обеспечивает клиент.

– PaaS (платформа как сервис) – позволяет пользователю установить в облачной инфраструктуре необходимое приложение, использующее операционные системы, языки программирования, библиотеки, СУБД и другие сервисы, предоставленные оператором.

● Оператор обеспечивает функционирование платформы и ее масштабирование при необходимости.

● Клиент занимается только поддержкой и работой приложения.

● Резервное копирование настраивает и обеспечивает оператор.

– SaaS (программное обеспечение как сервис) – клиент использует приложение, запущенное внутри cloud-среды оператора.

● Пользователи подключаются к нему с помощью различных протоколов (HTTP, RDP или VPN) и разных устройств, состав которых определен оператором, возможностями приложения (например, вся работа через веб-браузер).

● Поддержка приложения и аппаратуры полностью осуществляется оператором.

● Клиент может влиять только на ограниченное число настроек (заведение пользователей, назначение прав, включение/выключение дополнительных опций).

● Резервное копирование настраивает и обеспечивает оператор.

Рис. 1.6. Отличие технологий

Особый момент с обновлениями. Как было сказано выше, чем больше модификаций в ERP-системе в процессе внедрения, тем сложнее ее обновлять. Это накладывает ограничения на доступный вид облачного сервиса:

● Если компанию устраивает штатный функционал «из коробки», бизнес-процессы компании покрываются возможностями системы (или подстраиваются под них), то хорошо подходит модель SaaS.

● Если предполагается серьезная модификация системы в процессе внедрения, то потребуется модель PaaS.

● Если же ERP-автоматизация будет из нескольких интегрируемых систем от разных поставщиков, под которую потребуется специальная настройка окружения, то, возможно, хорошим вариантом будет IaaS.

При серьезных доработках ERP-системы ее обновление на актуальную версию будет отдельным мини-проектом и происходить автоматически, как обновления в облачном сервисе, не сможет. Нужно иметь своих специалистов или договор на осуществление этих работ со сторонней организацией.

Понятно, что чем больше компании придется настраивать и делать самостоятельно, тем выше будет стоимость эксплуатации системы, но тем меньше может стоить услуга по самому облачному сервису.

Тут нужно решить для себя:

● Хотим ли мы всем управлять и менять систему гибко, как нужно нам для наших устоявшихся бизнес-процессов.

● Хотим ли мы не думать о поддержке, а работать в готовом решении, принимая все его методики и ограничения как есть, подстраивая бизнес под них.

И в зависимости от этого выбрать тот или иной способ и определить (заранее) стоимость владения ERP-системой.

Подробнее об облачных технологиях компании «1С» можно почитать здесь:

http://v8.1c.ru/overview/Term_000000803.htm

Рис. 1.7. Облачный сервис компании «1С»

Система 1C: ERP присутствует в облачном сервисе «1С: Предприятие 8 через Интернет» по модели SaaS. Подробнее об этом – по ссылке: https://1cfresh.com/solutions/erp.

Нужно отметить момент резервного копирования информации и выбора поставщика услуги облачного сервиса. Все поставщики услуг обычно пишут на своих сайтах общие слова о гарантии работы 24/7, резервных копиях и о том, что «вам ни о чем не нужно думать, кроме самих данных и работы с ними». Но на практике это могут оказаться рекламные слова. Базу можно потерять безвозвратно. Нужно уточнить правила создания резервных копий, с какой глубиной они хранятся, сколько времени нужно на восстановление по запросу.

Автор знает такой пример недобросовестного предоставления облачной услуги, когда предположительно бэкап базы делался с недостаточной глубиной резервных копий, и при аппаратном сбое в бэкап стали писаться уже испорченные базы, а версии, где проблемы еще не было, уже не оказалось для восстановления.

В серьезных дата-центрах все многократно дублируется (рейд-массивы дисков с горячей заменой), используется полноценное резервное копирование, что гарантирует заявленный сервис и качество услуги. Так, например, в дата-центре «1С» для облачного сервиса стоит соответствующая аппаратура и обеспечивается бесперебойный уровень работы для конечного пользователя.

Глава 2. Как выбрать ERP-систему

2.1.Функциональные требования от ключевых сотрудников

Вопросам выбора конкретной ERP-системы предшествуют определенные процессы внутри компании: кто-то почему-то хочет ERP-систему. В компании есть группа лиц, заинтересованных в автоматизации своих процессов. Пусть даже это только итоговая финансовая отчетность и вычисление KPI по ней (цели финансового директора), а остальным сотрудникам «ничего от этой ERP не нужно, и так все хорошо». Либо причины иные – зачем ERP-система компании, рассматривалось в первой главе.

Кому-то система нужна, кому-то предстоит с ней работать. Это могут быть разные группы сотрудников, либо они пересекаются. Плохо, когда те, кому предстоит работать в системе, потребности что-то менять и автоматизировать не имеют. Возможны конфликты интересов внутри компании. В любом случае, если не рассматривать вопросы явного саботажа, а, наоборот, компанию рассматривать как единое целое, когда все сотрудники дружным коллективом работают на ее благо и в едином порыве, единогласно приветствуют процессы перехода на новую ERP-систему, тогда остаются практические вопросы: что и как должна уметь система, чем она поможет в работе за счет автоматизации. И как ее выбрать из представленных на рынке вариантов.

Проблемы конфликтов в коллективе будут рассмотрены ниже в главе про риски.

С системой предстоит работать разным подразделениям, от которых выделяются ключевые сотрудники (руководители подразделений или продвинутые исполнители бизнес-процессов). Эти специалисты формируют списки своих требований к системе, которые объединяются в общий сводный список требований к функциональности системы или, по-другому, список функциональных требований.

Ключевой сотрудник – это работник, от результатов труда которого зависит эффективная работа компании. Этот специалист четко понимает и выполняет бизнес-процессы внутри своего отдела (или функцию, за которую отвечает или является ее основным исполнителем).

Ключевые требования к ERP-системам:

● функциональность, соответствие уникальным особенностям бизнеса (отраслевая специфика);

● быстродействие, отказоустойчивость, масштабируемость системы;

● инструментарий для мониторинга системы, сбор статистики для анализа факторов, влияющих на быстродействие, аудит работы пользователей;

● возможность и инструментарий доработки функционала;

● разграничение прав доступа к данным и функциям;

● интеграция с существующими системами;

● наличие материалов для обучения пользователей и понятный интерфейс для их работы, предъявление низких требований к уровню квалификации пользователей;

● стоимость приобретения и владения ERP-системой;

● наличие проверенной методики внедрения (тиражирование готового решения).

Требования разделяются на функциональные и нефункциональные. Разница между ними простая: нефункциональные требования – это требования к характеристикам системы, а не к ее функциям. Функциональные требования отвечают на вопрос: «Что должна делать система?»

Критерии, которых нужно придерживаться при формулировании требований к КИС:

● полнота описания;

● правильность, точность и недвусмысленность формулировок;

● осуществимость (можно сделать в принципе);

● необходимость (только нужное, без лишних фантазий: «а давайте еще попросим…»);

● приоритет;

● проверяемость.

Формальное описание требований должно исключать использование «туманных» формулировок: «прозрачный», «гибкий», «быстрый», «приемлемый» и т. п. Проверяемость таких требований потребует указания четких критериев ожидаемых метрик. Иначе всегда можно не принять такую систему: «Получилось не прозрачно, не гибко и с неприемлемым временем работы». И нужно пойти и все переделать. Если уже понятно, что ожидается от системы, это нужно четко формулировать: «Отчет должен выводить такие-то аналитические разрезы и строиться не более 3 минут за месячный период по всем организациям». Впрочем, на начальном этапе сбора списка требований от заинтересованных сотрудников подойдут любые формулировки, они впоследствии будут уточняться и войдут в технические задания уже конкретными и формальными, иначе их просто нельзя будет сделать (программисту и настройщику системы сложно оперировать абстрактными понятиями).

Можно разделить требования к системе на три уровня:

● Есть глобальные цели автоматизации, которые, как правило, озвучивают спонсоры проекта (собственники бизнеса). Это что-то типа: повысить производительность/оборачиваемость, сократить запасы/издержки и т. д.

● Есть задачи линейных руководителей (снабжение, производство и т. д.), как правило, это какие-то функциональные блоки, глобальные консолидированные отчеты, доп. аналитика.

● Требования рядовых пользователей: интерфейсы, кнопки, отчеты, печатные формы, конкретные рабочие места.

При выборе системы крайне важно понимать цели и задачи руководителей, а детальные требования будут сформулированы уже на уровне ТЗ. К сожалению, часто встречаются предпроектные обследования или ТЗ, где большое внимание уделено мелочам («в системе необходима возможность вести справочник номенклатуры») и нет ключевых целей и задач самого проекта и системы автоматизации.

Сводный список требований должны составлять понимающие в вопросах автоматизации и бизнес-процессах компаний специалисты. Такого ответственного нужно еще найти. Возможно, что среди сотрудников компании его нет вовсе и нужно нанимать или привлекать внешних специалистов.

На практике встречается: поручить просто секретарю собрать все требования к системе по электронной почте со всех отделов в единый файл, без дополнительного анализа и формализации специалистом. Такие требования будут носить разрозненный характер, кто-то опишет свои потребности в автоматизации подробно, кто-то только «больные места» сегодняшнего дня. В любом случае в таких письмах будет не формализованное описание для передачи третьей стороне (участникам тендера по выбору ERP-системы), а описание для внутренних нужд, исходя из понимания реалий бизнеса и бизнес-процессов отделов в частности. То есть еще не факт, что такие описания даже в соседнем отделе поймут, если отделы достаточно независимы и, например, в холдинге это разные бизнес-единицы со своими юридическими лицами и удаленными офисами. А ожидается, что список требований поймут потенциальные исполнители будущего проекта внедрения. Собранную информацию (пусть и с помощью секретаря, которая всех знает и у всех все запросит) нужно переработать и формально описать в сводный список для передачи третьим лицам для организации тендера. При этом нужно сохранить информацию об изначальном авторе требования (не для передаче третьей стороне, а для внутренних нужд): это понадобится для последующих уточнений по требованию от исполнителей или согласования отмены либо переформулировки требования в процессе его анализа.

Полноценный и формально описанный список функциональных требований, если самостоятельно получить его до начала тендера сложно, можно составить уже в процессе, привлекая для этого внешних консультантов, участников этого тендера. При этом хоть в каком-то сводном виде для начала работ по уточнению и анализу его получить нужно.