Внедрение ERP на предприятии. Ресурсы.

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

Даже, если на стадии разрешения руководства на внедрение Вы уже выбрали ERP, и особенно если у Вас уже идет внедрение PLM или ещё какой-либо системы, необходимо провести аудит ресурсов.

Предыдущая статья: ERP. Промышленность. Шаг 1 – мы готовы.

Ресурс 1 - функциональность.

Для того, чтобы сразу отсеять тех, кто не подходит по базовой функциональности, важно, чтобы компания определилась с перечнем задач (крупных направлений), которые она хотела бы внедрить у себя в рамках ERP:

1. обязательный минимум;
2. желательный максимум;
3. целевой модуль – направление, наиболее критичное для реализации проекта.

В выборку должны попасть системы, имеющие обязательный минимум функциональности, перекрывающие или соответствующие желательному максимуму и с сильно развитым целевым модулем.

Если на этой стадии Вы уже выбрали ERP и подписали договор о внедрении, Вам необходимо очень тщательно проработать вопросы:

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

Ни в коем случае не убирайте из списка ERP систем новичков – системы, с малым или нулевым числом внедрений, но широкой функциональностью. К преимуществам работы с такими компаниями можно отнести:

1. возможность сильно торговаться по цене – они прекрасно понимают, какие двери перед ними открываются при получении положительной рекомендации, скажем от предприятия ВПК России, при удачном внедрении;
2. они действительно желают удачно внедриться – а этот мотивационный фактор со стороны руководства компании внедренца иногда может спасти проект от катастрофы, вплоть до замены своей команды на проекте на самые квалифицированные кадры компании;
3. они готовы сильно менять свою систему под ваши процессы, что очень облегчает процесс внедрения.

Ресурс 2 – управление разработкой.

Этот критерий определяет возможности доступа предприятия к доработкам системы своими силами.

Вариантов таких возможностей на сегодня на рынке представлено целых три:

1. система передается с открытым исходным кодом – на мой взгляд, это самый лучший вариант поставки системы, даже учитывая риски от сложностей установки обновлений на ваши доработки. Тем не менее – этот вариант позволяет Вам развивать систему в нужном вам направлении, делать это максимально быстро с контролем архитектурной целостности на вашей стороне и вести доработки даже после отказа от технической поддержки;
2. система передается с условно закрытым исходным кодом и имеет два слоя разработки – слой ядро, доступный для изменений только компании владельцу системы, и слой кастомизации (открытый исходный код) – доступный компании внедряющей у себя ERP. Слой кастомизации позволяет работать со всеми объектами системы, добавлять свои объекты, подменять функции ядра на собственные процедуры и т.д.;
3. система передается с закрытым исходным кодом и имеет возможности расширения функциональности, ограниченные наложением бизнес правил на формы и созданием дополнительных столбцов для обеспечения работоспособности новых бизнес-правил. Это худший вариант комплектации системы, который я называю – ИТ-рабством, привязывающий Вас навсегда к техподдержке и невозможности масштабного развития системы своими силами, ни во время действия техподдержки, ни после. Кроме того, при таком варианте поставки системы, во время внедрения консультанты будут практически всегда настаивать на варианте – ломаем процесс на предприятии, под систему, и крайне редко (почти всегда с увеличением стоимости внедрения) берутся за доработки системы под конкретного заказчика.

Ресурс 3 – единая среда.

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

Исходя из этого, я бы предложил придерживаться четырех основных требований к любым внедряемым системам:

• единая поддерживаемая ОС – идеальный вариант – кроссплатформенность всех внедренных систем или хотя бы их серверной части;
• единая СУБД;
• единый кроссплатформенный язык программирования клиентской части и отчетности;
• распространенные языки программирования.

Такие требования сильно упростят в будущем:

• подбор серверного железа и серверной ОС;
• подбор устройств, ОС и прикладного ПО конечных пользователей;
• подбор администраторов серверов – идеально очень высокий уровень знаний, но только в одной СУБД и одной платформе ОС;
• подбор разработчиков – идеально минимальное число языков программирования для поддержки максимального числа внедряемых систем.

Важно помнить, что со временем у Вас будет как минимум по два администратора на каждую СУБД и ОС. Безусловно, существует вероятность, что Вы где-нибудь найдете профи, который одинаково хорошо умеет администрировать скажем и ORACLE, и MS SQL, но найти таких двоих, если ещё у Вас не областной центр – будет не просто, а если и найти, то удержать заработной платой – будет очень и очень сложно.

Схожая картина и с администрированием ОС! На самом деле можно найти много людей, которые способны установить и работать и с Windows Server и Unix, ну кроме Solaris наверное, но знания этих людей будут на уровне продвинутых любителей, чего будет недостаточно, когда наступит момент, а он наступает всегда и у всех, нехватки серверных ресурсов. Это потребует оптимизации настроек СУБД + ОС + анализа узких мест в СУБД и ОС для выработки предложений по тюнингу настроек. И здесь нужна совсем другая квалификация администраторов.

Что же касается программистов и минимизации числа языков программирования – здесь тоже всё просто. Я не знаю ни одного предприятия, руководство которого сказало бы - для реализации ERP на предприятии разрешаем увеличить штат ИТ сотрудников предприятия в N раз или хотя на NN процентов.

Исходя из этого, Вы уже на этой стадии должны задуматься над тем:

1. сможете ли Вы найти на улице квалифицированных специалистов знающих одновременно все языки программирования, которые используются во внедренных и внедряемых Вами информационных системах?
2. имеется ли возможность обучить имеющийся персонал сразу всем языкам программирования, которые используются во внедренных и внедряемых Вами информационных системах?
3. сможете ли Вы платить таким универсалам заработную плату, при которой он вместо выполнения работы не будет занят исключительно поиском новой?
4. откуда вы в последующие периоды (3-10 лет) будете получать специалистов, которые будут знать все языки программирования, используемые во внедренных и внедряемых Вами информационных системах?

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

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

Ресурс 4 – потребности системы.

Накопление, обработка, хранение, изменение, контроль целостности, контроль и разграничение доступа и т.д. всё это требует ресурсов, которые предъявляются к носителям, передатчикам и обработчикам этой информации, а именно:

• серверу(ам) хранения информации;
• ОС и СУБД сервера(ов);
• серверу(ам) приложений системы;
• ОС и СУБД сервера(ов) приложений;
• рабочим местам конечных пользователей;
• ОС, ПО поддержания безопасности, прикладному ПО и клиента ERP системы;
• сетевому оборудованию.

Очень желательна информация от поставщика по требованиям к железу каждого компонента при работе ERP под разной нагрузкой при:

• максимальном плановом числе пользователей в системе (для справки – при правильном разделении функций в системе в периоды пиковой нагрузки «конец месяца, года», количество одновременно работающих пользователей в системе колеблется от 60 до 80% от общего числа пользователей, получивших доступ к системе);
• при числе пользователей в системе в 3, 5 и 10 раз меньшем.

Кроме того, желательно получить информацию по:

• статистике (аналогии) роста данных базы на каждую 1 млн. – 10 млн. записей в базе данных или хотя бы по годам;
• механизмам резервного копирования и восстановления, и требованиям к железу для обеспечения приемлемого времени восстановления системы.

Необходимо помнить, что при внедрении любой системы, для обеспечения её поддержки и развития придется держать активными несколько экземпляров базы и системы:

1. промышленный экземпляр системы;
2. эталонный экземпляр – действует на стадии внедрения и действия технической поддержки, необходим для установки обновлений на экземпляр, содержащий только код владельца системы;
3. экземпляр для разработчиков – необходим весь период внедрения и эксплуатации системы, доступен только разработчикам;
4. экземпляр для тестирования (желательно с ресурсами близкими к промышленному экземпляру или меньшими, но кратным масштабом для возможности оценки быстродействия разработок на клиентской стороне, после переноса на боевой экземпляр) – необходимы максимально актуальные данные в объектах базы с возможностью изменения данных для подготовки тестовых примеров;
5. экземпляр под обучение пользователей - необходимы максимально актуальные данные в объектах базы с возможностью изменения данных для подготовки примеров для обучения пользователей;
6. резервная копия каждого экземпляра с разным временем на восстановление, а следовательно и разными потребностями в ресурсах.

На всё это нужны будут физические и виртуальные ресурсы! Эти данные позволят Вам:

• оценить затраты на организацию и подключение одного клиентского рабочего места;
• выбрать сервера, способные обеспечить требуемую производительность и доступность всех экземпляров системы на следующие несколько лет.

Ресурс 5 – зрелость и открытость.

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

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

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

Ресурс 6 - команда.

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

1. Команда от компании внедренца + команда от предприятия, внедряющего ERP. Это наиболее распространенный подход к внедрению крупных систем, при котором за предприятием, практически на весь период внедрения закрепляется команда консультантов, в задачу которых входит помощь (консультации, демонстрации, убеждение, обучение, адаптация системы и персонала) в реализации проекта на предприятии. По большей части эта команда должна работать со службами ИТ предприятий, а уже те, непосредственно с подразделениями, но чаще всего консультантов также привлекают к работе с подразделениями. При  таком подходе - 50% успеха проекта зависит от уровня, опыта и веса мнения руководителя от консультантов в компании, где он числиться.
2. Команда от предприятия, внедряющего ERP. Не столь часто реализуемый подход, но также имеющий право на жизнь, доказавший это удачными внедрениями в России. Компания, собирающаяся внедрять ERP, нанимает в свой штат не менее 2 (двух) специалистов уровня архитекторов системы, имеющих опыт внедрения ERP, желательно (но не обязательно) выбранной к внедрению ERP.

Ресурс 7 – что, когда, зачем.

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

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

В идеале, в договоре должно быть  только два приложения, описывающих что внедряем, когда и с какой целью:

1. ТЗ – техническое задание на внедрение: разбитое на этапы или модули подробное перечисление функций, которые должны быть реализованы на предприятии;
2. План-график работ по проекту, содержащих следующую информацию:

• укрупненный состав работ по этапам, совпадающим с этапами из ТЗ;
• что должно появиться на предприятии в результате внедрения этапа – т.е. какие документы и функции должны быть внедрены на предприятии, чтобы этап был признан реализованным в полном объеме;
• длительность этапа – период реализации этапа с точностью до квартала или месяца, в зависимости от понимания задачи на этапе подписания договора;
• стоимость этапа – а куда без этого.

Помните – впереди, по мере внедрения, Вас ждёт не одно подписание уточняющих, дополнительных соглашений к этому основному договору.

Ресурс 8 – финансирование.

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

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

1. стоимости договора внедрения;
2. стоимости лицензий и серверных, и клиентских;
3. приобретение и развертывание ИТ инфраструктуры, включая конкретные рабочие места будущих пользователей системы (без мебели, только ИТ);
4. стоимость серверного оборудования;
5. стоимость администраторов баз данных и ОС;
6. стоимость подготовки ИТ персонала.

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

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

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

Продолжение: Как внедрять ERP на предприятии?

Автор: Андрей Лабутин