proerp

Искусственный интеллект (ИИ) в системах планирования ресурсов предприятия (ERP) означает интеграцию технологий ИИ, таких как машинное обучение (ML), обработка естественного языка (NLP) и прогнозная аналитика, в ERP-системы. Эти системы на основе ИИ могут автоматизировать рутинные задачи, предоставлять расширенный анализ данных и прогнозирование, а также улучшать принятие решений. Цель внедрения ИИ в ERP — повышение операционной эффективности и оптимизация бизнес-процессов.

Почему ИИ в ERP важен?

Благодаря ИИ традиционные ERP-системы превращаются в интеллектуальные платформы, которые обучаются на данных, адаптируются к изменениям и оптимизируют бизнес-аналитику в реальном времени, повышая общую эффективность и сокращая затраты. Согласно отчету IBM Institute for Business Value, компании, применяющие генеративный ИИ для анализа данных, уже демонстрируют более высокую прибыльность.

ERP-вендоры обычно проектируют свои системы как набор модульных приложений, которые вместе охватывают все аспекты бизнеса — от финансов до закупок и логистики цепочки поставок. С момента появления термина «ERP» в 90-х годах индустрия ERP-решений выросла до рынка объемом $44 млрд в год. Сегодня многие ведущие корпорации используют ERP-системы для получения «единого источника истины» по всему бизнесу.

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

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

Продвинутые модели машинного обучения и NLP сделали ERP-системы более удобными и точными, открыв новую эру интеллектуального бизнес-ПО. Влияние ИИ на ERP подтверждается недавними сделками, такими как партнерство Microsoft и OpenAI на $13 млрд и выпуск ИИ-ассистента для Microsoft Dynamics 365. Другой ведущий вендор, SAP, в 2023 году представил генеративного ИИ-ассистента «Joulie».

Типы ИИ в ERP

ERP-системы используют ИИ-технологии для улучшения управления бизнес-процессами. Среди них:

• Прогнозная аналитика

• Обработка естественного языка (NLP)

• Роботизированная автоматизация процессов (RPA)

• Машинное обучение (ML)

• Чат-боты и виртуальные ассистенты

• Распознавание изображений

Прогнозная аналитика

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

Обработка естественного языка (NLP)

Позволяет ERP-системам понимать и отвечать на человеческую речь, улучшая взаимодействие с пользователями. Благодаря большим языковым моделям (LLM), таким как ChatGPT, NLP-инструменты стали более точными и контекстно-релевантными.

Например, NLP может анализировать неструктурированный текст (например, письма клиентов) для оценки настроений или обрабатывать запросы сотрудников в неформальном стиле, делая ПО более интуитивным.

Роботизированная автоматизация процессов (RPA)

Автоматизирует рутинные задачи (например, ввод данных, миграцию файлов) с помощью «ботов». ERP-системы с RPA могут автоматически генерировать отчеты, распределять HR-документы или управлять данными клиентов.

Машинное обучение (ML)

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

Чат-боты и виртуальные ассистенты

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

Распознавание изображений

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

Генеративный ИИ в ERP

Генеративный ИИ имитирует человеческий интеллект, добавляя новые функции в ERP-системы. Например:

• Генерация отчетов — автоматическое создание бизнес-отчетов из сырых данных.

• Создание контента — написание писем, маркетинговых материалов или документации.

• Сценарное планирование — анализ регуляций и предложение рекомендаций (например, по сокращению углеродного следа).

Примеры использования ИИ в ERP

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

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

3. Автоматизированная обработка счетов
   NLP и RPA ускоряют обработку счетов, снижая ошибки. SAP и Oracle используют ИИ для верификации накладных.

4. Поддержка клиентов
   ИИ в CRM автоматически решает типовые вопросы и генерирует письма (как в SAP CRM).

5. Управление персоналом
   Например, SAP SuccessFactors предлагает персонализированное обучение и автоматически подбирает кандидатов.

6. Управление цепочками поставок
   ИИ оптимизирует логистику, отслеживает заказы и прогнозирует сбои (как в IBM Sterling).

Преимущества ИИ в ERP

• Повышенная точность — снижение ошибок за счет автоматизации.

• Оптимизация процессов — быстрая адаптация к изменениям на основе аналитики.

• Рост продуктивности — сотрудники освобождаются от рутины.

• Улучшенная безопасность — ИИ быстрее обнаруживает угрозы.

Лучшие практики внедрения ИИ в ERP

1. Управление данными — обучение ИИ на качественных и защищенных данных.

2. Масштабируемая инфраструктура — облачные или гибридные решения.

3. Постоянный мониторинг — регулярные обновления системы.

4. Стратегия интеграции — соответствие бизнес-целям.

ИИ на отечественном ERP-ландшафте

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

1. Прогнозная аналитика в ритейле
   Крупные российские розничные сети, такие как «Магнит» и X5 Group, используют ERP-системы с элементами ИИ для прогнозирования спроса и оптимизации цепочек поставок. Алгоритмы машинного обучения анализируют исторические продажи, сезонность и внешние факторы (например, погоду), чтобы минимизировать излишки или дефицит товаров.

2. Автоматизация документооборота в госсекторе
   Некоторые государственные корпорации (например, «Ростех» и «Росатом») внедряют NLP и RPA в свои ERP-системы для автоматической обработки счетов, накладных и контрактов. Это ускоряет процессы согласования и снижает бюрократическую нагрузку.

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

4. Предиктивная аналитика в промышленности
   Компании вроде «Северстали» и «Норникеля» тестируют ИИ-модули для прогнозирования износа оборудования. Датчики IoT собирают данные о состоянии техники, а алгоритмы предсказывают оптимальное время для обслуживания, предотвращая аварии.

Отставание российского ERP-ландшафта в сфере ИИ

Несмотря на отдельные успешные кейсы, российский рынок ERP серьезно отстает от западного в интеграции ИИ. Основные причины:

1. Ограниченные технологические возможности

   • Большинство российских ERP-систем (1С, Галактика, и т.д.) изначально не проектировались для работы с ИИ.

   • Нехватка вычислительных мощностей и облачных решений затрудняет внедрение сложных ML-моделей.

2. Дефицит данных для обучения моделей

   • Качественные дата-сеты, необходимые для обучения ИИ, часто недоступны из-за закрытости корпоративных данных.

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

3. Санкционные ограничения

   • После 2022 года усложнился доступ к западным ERP-платформам (SAP, Oracle), которые лидируют в области ИИ.

   • Российские аналоги (например, «Постгрес ПРО» или «Р7-Офис») пока не могут предложить сопоставимый функционал.

4. Недостаток экспертизы

   • В России мало специалистов, способных разрабатывать и внедрять ИИ-модули для ERP.

   • Компании часто не готовы инвестировать в долгосрочные ИИ-проекты из-за неочевидного ROI.

Экспертные мнения, новости и тренды в части корпоративных информационных систем в телеграм-канале.

Крупные игроки российской IT-отрасли, входящие в АПКИТ (Ассоциацию предприятий компьютерных и информационных технологий), высказались против создания консорциума для разработки государственной ERP-платформы. Об этом свидетельствует протокол заседания правления, где присутствовали Филипп Генс («Ланит»), Борис Нуралиев (1С), Илья Сивцев («Астра») и другие.

Позиция рынка: Лидеры отрасли считают, что тратить бюджетные средства на новую систему неразумно, поскольку в России уже есть готовые ERP-решения.

Конфликт с госполитикой: Проект также противоречит схеме «рынок в обмен на инвестиции», запущенной в 2023 году. Согласно ей, компании вкладывают миллиарды в развитие своих продуктов, получая льготы при госзакупках.

Фактически это официальная позиция ведущих разработчиков ERP-решений, закрепленная документально, но не на словах.

Ситуация выглядит предсказуемой: речь идет о централизации вокруг одного из самых прибыльных сегментов IT. Примечательно, что аналогичные процессы в других сферах — госучете, медицинских информационных системах — ранее проходили без возражений. Тогда сотни интеграторов лишились работы, а рынок перешел под контроль крупных вендоров… тех самых, что сейчас заседают в правлении АПКИТ!

Источник: ERP: Решения для бизнеса

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

Мнение

1. Необходимость импортозамещения
   Создание отечественной ERP-системы – логичный шаг в условиях санкций и ухода западных IT-решений. Такие системы, как SAP и Oracle, долгое время доминировали в корпоративном секторе, и их замещение – вопрос не только технологический, но и стратегический. Если Россия сможет предложить конкурентоспособный продукт, это снизит зависимость от иностранного ПО и укрепит цифровой суверенитет.

2. Стоимость и сроки: адекватны ли?
   $1 млрд за 10 лет – сумма значительная, но не запредельная для разработки ERP-масштаба. Для сравнения, SAP ежегодно инвестирует сотни миллионов в развитие своих продуктов. Вопрос в эффективности расходов: будет ли проект прозрачным, или часть бюджета «растворится» в бесконечных пилотных версиях и доработках? Важно избежать сценария, при котором через 10 лет получим устаревшую систему, неспособную конкурировать даже с открытыми аналогами.

3. Кто войдет в консорциум и каковы риски?
   Если в разработку включатся крупные игроки (например, "1С", "Русал", "Северсталь"), это повысит шансы на успех. Однако есть опасность, что проект превратится в бюрократическую имитацию с бесконечными согласованиями. Кроме того, ERP – это не только код, но и экосистема: интеграции, поддержка, обучение. Если бизнесу будет невыгодно переходить на новую систему, даже господдержка не спасет.

4. Технологический суверенитет vs. глобальная конкуренция
   Российская ERP должна быть не просто заменой SAP, но и современным продуктом с поддержкой AI, блокчейна (если это актуально) и облачных технологий. Иначе бизнес, особенно работающий на экспорт, просто не примет её. Кроме того, важно обеспечить совместимость с международными стандартами – иначе компании окажутся в цифровой изоляции.

Перспективы

Инициатива Мишустина – правильный шаг, но сложный. Успех зависит от трех факторов:

• Реальные потребности бизнеса (а не просто желание чиновников отчитаться).

• Технологическая гибкость (чтобы система не устарела ещё до релиза).

• Экономическая целесообразность (чтобы компании добровольно переходили на новое ПО, а не под административным давлением).

Если проект реализуют грамотно, это может стать прорывом для российской IT-индустрии. Если нет – ещё одной дорогой, но бесполезной "импортозаместительной" инициативой.

Источники

interfax, ERP: Решения для бизнеса

Исходные данные

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

Технологический стек — платформа 1С и пять здоровенными баз УПП к ней.

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

Задача – привести управленческий учет к стандартам ЕПСБУ, то есть стандартам единого государственного плана счетов.

Перед участием в конкурсе

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

Потенциально возможные варианты реализации:

1. Попытаться реализовать в УПП (на обычных формах!) стандарты ЕПСБУ. Если говорить проще, то взять 1С:Бухгалтерия государственного учреждения 2 (1С:БГУ 2) и попытаться передрать оттуда и адаптировать целевой функционал. Туда же докинуть то, что требуется из 1С:Зарплата и кадры государственного учреждения 3 (1С:ЗКГУ 3) – здесь существенно меньше.

2. Перевести заказчика на ERP 2, заимствуя все необходимое из тех же 1С:БГУ 2 и 1С:ЗКГУ 3.

3. Написать нечто напоминающее интеграционную шину, которая будет обмениваться учетными данными с 1С:БГУ 2 и 1С:ЗКГУ 3. Последние две конфигурации в рамках такой схемы, очевидно, еще нужно внедрить.

4. Дописать производственный блок и все остальное в рамках 1С:БГУ 2 и перевести заказчика на 1С:БГУ 2 и 1С:ЗКГУ 3.

Первые два варианта кажутся наименее рабочими. Почему?

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

• Разработка на базе морально и технически устаревшего программного продукта в рамках первого варианта кажется не привлекательной.

• Объем работы представляется наиболее масштабным по сравнению с остальными вариантами. По крайней мере на текущий момент...

• Коммерческие перспективы для нашей компании в рамках доработок и технологических решений, которые будут реализованы, отсутствуют.

Таким образом, остаются варианты 3 и 4. На мой взгляд, наиболее привлекательным является третий вариант. Его единственная, но серьезная уязвимость — большое количество обменов. В рамках этого варианта мы получим набор программных продуктов, непрерывно обменивающихся данными: 1С: УПП — 1С: БГУ 2, 1С: УПП — 1С: ЗКГУ 3, 1С: БГУ 2 — 1С: ЗКГУ 3. Заказчики обычно относятся скептически к таким сложным и тонким обменам.

Четвертый вариант уступает третьему практически всем, за исключением обменов. Здесь он только один – стандартный (ну или почти стандартный в нашем случае) обмен между 1С:БГУ 2 и 1С:ЗКГУ 3.

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

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

К чему это все?

Попробую отражать здесь ход выполнения проекта: как все это будет происходить, какие решения будут приниматься с обеих сторон, какие трудности будут возникать и как они будут решаться (если будут).

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

Предисловие

Рассказ руководителя одного из подразделений компании, в которой был запущен проект по внедрению новой управленческой системы. В качестве стека технологий была выбрана платформа 1С, в качестве программного продукта – 1С:ERP 2. История пойдет от первого лица, непосредственно от очевидца и участника событий.

Заказчик

Компания занимается торговлей различными техническими девайсами и комплектующими к ним: закупка товара за рубежом, многоступенчатая система логистики, реализация в России по средствам прямых договоров, а также через государственные закупки, включая гособоронзаказ. Ведется деятельность в рамках "интеркампани". Несколько офисов в России и Китае. Есть свое развивающееся производство.

Что из себя представляла старая информационная система?

Самопал, разработанный давно канувшей в лету IT–компанией, насчитывающей на пике своего могущества не более 10 человек. Система по сути своей визуально представляла одну огромную таблицу в несколько сотен колонок. Работая в программе, вы быстро понимаете, что самая нужная кнопка мыши – это «колесико», потому что будете проматывать экраны вправо, влево, вверх и по диагонали! Плюсы очевидны: после недели работы вы с большой вероятностью накачаете себе правую руку…

Подготовка к проекту

Новый IT–директор (будем звать его Геннадий), находясь две недели в должности, приходит к бескомпромиссному, ну и естественно, самому логичному выводу: нужно внедрять новую систему вчера! На всё про всё потребуется год, бюджет — 120 миллионов рублей, ну и контракт с IT–интегратором, где, уж так сложилось, он является соучредителем! Руководство компании задает резонный вопрос, а как же провести исследование рынка, собрать КП и прочие никому не нужные вещи?.. На что собственники от Геннадия получают ответ, что данные мероприятия для слабаков и неуверенных в себе людей!

Но все же здравый смысл восторжествовал! Пригласили с десяток потенциальных подрядчиков. На общих правах были проведены экспресс–обследования текущего положения дел. Средняя стоимость запуска системы, исходя из всех КП, составила 55 миллионов рублей вместо изначально предложенных Геной 120–ти…

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

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

По идее проект должен был мчаться с разгона в пропасть уже на этом моменте. Однако повезло… Технический директор (будем звать его Алексей) оказался в последствии одним из тех людей, которые позволили реализовать проект хоть в какой–то степени. Стоит отметить, что таких людей было немного…

Подрядчик

Здесь все оказалось весьма прозаично! Выбрали того, кто предложил самую низкую цену. Я бы даже сказал, экстремально низкую по сравнению со всеми остальными соискателями… Но сей факт по загадочным причинам никого не напугал… Возможно подумали, что дескать, если не получится, то хотя бы будет недорого…

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

Технические особенности будущей управленческой системы

• Более 70 уникальных рабочих столов: индивидуальных интерфейсов для различных групп пользователей (в информационной системе работает более 200 пользователей);

• Прослеживание стадий логистики товара в любой момент времени (дополнительные аналитические разрезы, фигурирующие во всех отчетных формах);

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

• Измененная логика формирования себестоимости в рамках специфики бизнес–процессов;

• Интеграция более чем с 80 специализированными онлайн–сервисами;

• Создание многократно используемого (для исключения параллельной работы в двух программах) механизма переноса данных из старой информационной системы в 1С:ERP (размер информационной база–источника — более 1 Тбайт).

Как шел процесс

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

• Месяц 1 — 3

  • 👍 Налаживание отношений между коллективом подрядчика и заказчика.

  • 🤦‍♂ Недостаточное внимание со стороны сотрудников заказчика к процессу внедрения на начальном этапе.

• Месяц 4

  • 👍 Увеличение количества аналитиков и методологов со стороны исполнителя.

  • 🤦‍♂ Полная смена всей команды исполнителя, включая руководителя проекта, через 3 месяца после начала работы. Здесь, кстати, задержка введения системы в эксплуатацию на 3 месяца выглядит весьма ожидаемо. Как раз то на то и выходит.

• Месяц 5

  • 👍 Создание тестовых групп из сотрудников заказчика с сопутствующим премированием и штрафами.

  • 🤦‍♂ Бойкотирование и откровенный саботаж всего мероприятия со стороны сотрудников заказчика.

• Месяц 6

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

  • 🤦‍♂ Изменение №1 технического задания с формулировкой «мы не могли всего учесть».

• Месяц 7

  • 👍 Опять налаживание отношений между коллективом подрядчика и заказчика. Руководителям проекта с обеих сторон удалось создать здоровою рабочую атмосферу, превратить два коллектива практически в единую команду.

  • 🤦‍♂ Изменение №2 технического задания с формулировкой «без этого мы никак не сможем работать».

• Месяц 8

  • 🤦‍♂ Решение делегировать специалистам заказчика разработку механизма миграции учетных данных из старой системы в 1С:ERP. Понятие клиент–серверной парадигмы для них являлось чем–то из области теории нано–шлейфов, поэтому несколько миллиардов раз в цикле на клиенте вызывать серверные функции – это вполне ОК, норм… Отладка механизма переноса учетных данных затянулась почти до самого запуска системы.

• Месяц 9

  • 🤦‍♂ Изменение №3 технического задания с формулировкой «за время проекта бизнес–процессы сильно изменились».

• Месяц 10

  • 👍 Не поддаваться давлению со стороны собственников в стиле «все сроки уже прошли, нужно начинать работать в новой программе как есть, отлаживать можно потом, так мы никогда не начнем…»

• Месяц 11

  • 👍 Нахождение специалистов поддержки со стороны исполнителя физически на местах у заказчика.

• Месяц 12

  • 👍 Запуск новой управленческой системы!

Что было дальше?

Казалось бы, плюс–минус happy end! Новая ERP–система введена в эксплуатацию! Нужно выходить на закрытие месяцев, расчет статистических показателей, регламентированную отчетность, увеличение производительности системы и рефакторинг. Про расширение функциональных возможностей, повышение эргономики и прочие хотелки тоже не будем забывать…

Но тут, как гром среди ясного неба, происходит замена руководителя проекта со стороны заказчика (напомню, мы называли его Алексей). Его обязанности ограничивают исключительно техническим отделом, отстраняют от ERP. Как оказалось, в последствии это было начало конца…

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

Новым руководителем ERP–отдела назначают одного из программистов заказчика (назовем его Семён). С какой целью была предпринята такая предельно рискованная рокировка – тайна, покрытая мраком…

Хронология событий после вступления Семёна в должность ИТ–директора

• Приостановка работы с подрядчиком на 1,5 месяца, инициированная Семёном;

• Перевод взаимодействия с подрядчиком с абонентского варианта на почасовой учет работ (потрясающее решение в рамках проекта такого масштаба);

• Стоимость услуг подрядчика увеличивается в 2,5 раза в рамках почасовой тарификации;

• Подсчет и обсуждение часов за выполненные подрядчиком работы занимает большую часть времени у Семёна и руководителя проекта со стороны подрядчика;

• Попытки стремительного увеличения собственного IT–отдела компании (причем рекрутировались только программисты… аналитик, я так понял, это вообще ненужная позиция);

• Попытки увести специалистов у подрядчика;

• Разрыв отношений с подрядчиком;

• Предельное ухудшение отношений с руководителями отделов и прочими сотрудниками собственной компании;

• Обрушение линии поддержки программного продукта, ибо собственными силами не справлялись;

• Набор в отдел сопровождения ERP порядка 20 человек, практически не взаимодействующих друг с другом (очень разделяй и очень властвуй);

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

• Отсутствие полной управленческой картины у финансово–экономического отдела, отдела закупок, отдела продаж и отдела по логистике;

• Невозможность выплаты переменной составляющей заработной платы (процентов) менеджерам ввиду крайне скудной информации о финансовых показателях (проценты платятся с прибыли всем: продажникам, закупщикам, логистам, таможенным брокерам);

• Уход в полном составе одного из отделов продаж;

• Безуспешные (вот уже два месяца) поиски нового подрядчика (никто из 1С–франчайзи и прочих интеграторов не хочет во все это вписываться)…

Что в итоге

Система деградирует семимильными шагами — это положение дел на текущий момент.

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

Причин такого мегапрофака можно перечислить великое множество! Я же в свою очередь остановлюсь на тех которые мне озвучил очевидец событий и добавлю немного через призму своего опыта:

• Ошибочное решение собственников бизнеса: если система введена в эксплуатацию, то "скрипач теперь не нужен, дядя Вова";

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

• Кадровые ошибки заказчика при формировании собственного IT–отдела: как минимум начинать нужно было с грамотного IT–рекрутера, который бы профессионально выстроил систему подбора IT–специалистов;

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

• Отсутствие понимания со стороны руководства, что хороший программист или аналитик не равно хороший руководитель. Чтобы руководить нужно не ненавидеть людей и уметь брать на себя ответственность! Семён этим критериям не соответствовал от слова совсем. Алексей и руководитель проекта со стороны подрядчика соответствовали полностью.

• Ошибка Семёна — он родился (со слов автора).

Если отозвалось, то можно подписаться...