Понравилась статья - поделись ею в соцсетях)

Print Friendly, PDF & Email

Так уж получилось, что последние несколько лет я занимаюсь внедрениями ERP ODOO и выполняю роль бизнес/системного аналитика на таких проектах. Наверное внедрение ERP-систем один из самых сложных IT проектов, у которого большое количество рисков и неопределенностей. Об этом свидетельствует и статистика: большая часть таких проектов заканчивается неудачей и причин почему так получается великое множество.

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

Что такое ERP-система и зачем она компании?

Понятие ERP-системы

Сам термин ERP – это аббревиатура из английских слов Enterprise Resource Planning, дословно «планирование ресурсов предприятия». Такие системы (и сам термин) были наследием систем MRP и MRP II класса (англ. Material Requirements Planning – планирование потребности в материалах). Но за счет включения в себя множества других модулей или подсистем (тоже имеющих устоявшиеся двух-трехбуквенные обозначения) ERP стало собирательным наименованием систем планирования, учета, управления и принятия решений.

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

Определение термина ERP, которое дает APICS (American Production & Inventory Control Society, Американское общество управления производством и распределением материалов): Планирование ресурсов предприятия (ERP) – это рамки, основа (framework) для организации определения и стандартизации бизнес-процессов, необходимых для эффективного планирования и контроля организации таким образом, чтобы организация могла использовать внутренние знания для поиска внешнего преимущества.

ERP состоит из большого количества элементов (модулей)

  • MES (Manufacturing Execution System) – производственные управляющие системы;
  • WMS (Warehouse Management System) – системы управления складами;
  • CRM (Customer Relationship Management) – системы управления взаимоотношениями с клиентами;
  • SCM (Supply Chain Management) – системы управления цепочками поставок;
  • TMS (Transportation Management System) – системы управления транспортировками;
  • PDM (Product Data Management) – системы управления данными о продуктах (изделиях);
  • KPI (Key Performance Indicators) – ключевые показатели эффективности. Входят во многие системы показателей, например, BSC (Balanced Scorecard) – сбалансированная система показателей. Объединяются в отдельный блок (подсистему) визуализации показателей (монитор/витрина целевых показателей);
  • EAM (Enterprise Asset Management) – управление основными фондами предприятия (процессами эксплуатации и ремонта). ТОиР – техническое обслуживание и ремонт;
  • HRM (Human Resources Management) – управление персоналом;
  • CPM (Corporate Performance Management) – система управления эффективностью предприятия. Синонимы для такого класса системBPM (Business Performance Management), EPM (Enterprise Performance Management), SEM (Strategic Enterprise Management);
  • MDM (Master Data Management) – системы управления мастер-данными (сведение и управление общей НСИ – нормативно-справочной информацией);
  • BPMS (Business Process Management System) – системы управления бизнеспроцессами.

Например в ERP Odoo есть следующие модуля (это не конечный список, а просто пример):

Отличие ERP-системы от учетной бухгалтерской системы

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

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

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

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

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

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

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

Нужно договариваться, сводить все к единой НСИ. Иначе будет «лебедь, рак и щука» – кто куда, по своим интересам.

В общем случае в ERP-системе больше разнообразных «небухгалтерских» данных, нефинансовых в том числе, но очень важных для управления компанией. Можно процитировать Генри Форда: «Когда я изучаю свой баланс, я не могу увидеть там двух вещей: цены моей марки и стоимости моих кадров. Однако именно они и делают меня богачом». В современных бухгалтерских программах есть и цены, и ставки зарплаты, но вот в классической бухгалтерской отчетности этого действительно нет.

Зачем ERP-система компании?

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

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

Итак ERP-cистема может быть необходима:

  • для реального понимания бизнеса и управления им;
  • прозрачности данных для аудиторов;
  • предоставления требующейся оперативной отчетности по МСФО для родительской компании или инвесторов;
  • повышения ценности компании, деловой репутации (гудвил в терминах МСФО), т. к. брендовая система автоматизации, по мнению аудиторов, один из необходимых критериев;
  • как конкурентное преимущество: снижение затрат (ФОТ, себестоимость продукции, оборачиваемость склада, ассортиментное планирование) – инструмент для захвата рынка;
  • для внедрения бюджетирования – тактического и стратегического;
  • введения системы KPI и контроля за ними;
  • поддержки «цифровой экономики», как модель предприятия и продукции;
  • переход к «Интернету вещей» – новый уровень контроля оборудования и/или конечной продукции.

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

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

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

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

Иногда даже один какой-то пункт и его экономический эффект окупает многолетнее внедрение ERP-системы. А если польз несколько – совсем хорошо!

Затраты на владение системой

Если вы решили внедрит такую систему, то не стоит забывать о затратах на владении системы.

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

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

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

Из чего будет состоять стоимость системы для потребителя?

  • стоимость «коробочной» версии ERP;
  • стоимость лицензий на одно рабочее место;
  • стоимость лицензий на сервер;
  • стоимость сервера системы управления базами данных (СУБД). Это ПО от сторонних поставщиков. Там своя лицензионная политика: на пользователей, на ядра процессора;
  • стоимость аппаратного сервера (нескольких серверов), куда все будет устанавливаться. Возможно, нужен не один, а несколько серверов с объединением в кластер, либо настройки идут через виртуальные машины на очень мощном едином сервере;
  • серверные операционные системы для серверов;
  • системы резервного копирования;
  • услуги по пусконаладке серверов и встраиванию их в сетевую инфраструктуру компании;
  • квадратные метры помещения для размещения аппаратуры, вентиляция, аккумуляторные блоки для бесперебойной работы серверов в режиме 24/7;
  • затраты на организацию системы удаленного доступа к системе;
  • консалтинговые услуги проекта внедрения ERP-системы;
  • зарплата сотрудников, задействованных частично или полностью на проекте внедрения со стороны заказчика (включая сотрудников, отвлекаемых от основной работы на время обучения новой системе);
  • обновление или приобретение новых компьютеров и/или мониторов для рабочих мест сотрудников – будущих пользователей.

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

  • Техническое обслуживание серверов (затраты на ИТ-специалиста в штате или приглашаемого на время).
  • Подписка на сопровождение и обновления (для западных ERP-систем это значительная статья расходов, т. к. стоимость подписки может быть 20–30 % от стоимости всех лицензий на КИС в год).
  • Затраты на службу внутренней поддержки пользователей или внешних специалистов, привлекаемых для решения возникающих в работе вопросов и небольших доработок (включая затраты на командировки, если это требуется, например, для обучения новых сотрудников в филиалах).
  • Регулярные обновления системы на новые версии, содержащие новый функционал, исправление ошибок и, главное, поддержка изменений законодательства (для систем автоматизации бухгалтерского и налогового учета). Нужно учесть, что чем больше доработок и изменений было внесено в «коробочную» версию ERP при внедрении, тем дороже и сложнее происходит такое обновление.
  • Обновление (upgrade) аппаратуры серверов для масштабирования при росте нагрузки или поломках/устаревании/износе.
  • Дополнительные регулярные расходы на возникшую из-за появления ERP инфраструктуру в компании.

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

Как внедрить ERP-систему и при этом выжить

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

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

Управление проектами в мировой практике как правило совершается проектными менеджерами и они в своей работе руководствуется PMBOK ( Project Management Body of Knowledge) – сводом знаний по управлению проектами, разрабатываемый и поддерживаемый институтом по управлению проектами PMI.

Проектный треугольник

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

Условно его идею можно сформулировать в одну строку:

«Быстро – Качественно – Дешево: выберите любые два пункта».

Из этого получается:

  • хочется быстро и качественно – будет дорого;
  • нужно дешево и качественно – будет долго;
  • нужно быстро и дешево – будет, очевидно, некачественно.

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

Все эти величины имеют верхние пределы:

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

Внесение изменений в одну из сторон треугольника меняет как минимум еще одну связанную сторону.

Нематериальность выходной продукции в проекте автоматизации создает иллюзию того, что для внесения изменения в список требований или в уже реализованные требования нужны незначительные усилия. Это заблуждение! Для понимания можно приводить аналогию со стройкой и сносом и переделкой кирпичной стены, если ее нужно сдвинуть, например, на 15 см. «Кирпичики» кода системы тоже нужно разобрать и перенести – пусть это не физические, а умственные усилия исполнителей, но время это занимает, как и перекладка кирпичей.

Это как показывает моя практика очень большая проблема в таких проектах. Если заказчик на начальной стадии проекта не знает, что ему точно нужно, то потом он может захотеть что-то абсолютно противоположное со словами «Я это и имел ввиду» или «Я без этого не могу работать. Без этого ваша система мне не нужна».

Далее в таком треугольнике проявляется конфликт интересов заказчика и исполнителя:

  • Цели заказчика проекта: сделать побольше (увеличить объем работ), побыстрее (сроки сократить), подешевле (меньше ресурсов потребуется).
  • Цели исполнителя: заработать максимум денег, закрыть потребности заказчика в приемлемом качестве. А это: сделать поменьше (минимизировать объем работ), подольше (увеличить срок, чтобы все успеть без авралов), подороже (увеличить бюджет).

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

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

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

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

Как ни крути, но изменить только одну сторону треугольника не получается.

В общем случае получается четыре подхода:

  • Фиксируем объем работ: меняем сроки и бюджет проекта.
  • Фиксируем бюджет проекта: меняем сроки и объем работ.
  • Фиксируем сроки: меняем объем работ и бюджет проекта.
  • Меняем все стороны треугольника.

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

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

методологии и проектный треугольник

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

Реинжиниринг бизнес-процессов

Реинжиниринг бизнес-процессов (англ. business process reengineering) – это фундаментальное переосмысление и, возможно, радикальное перепроектирование бизнес-процессов компании для достижения максимального эффекта производственно-хозяйственной и финансово-экономической деятельности. Результат пересмотра процессов оформляется соответствующими организационно-распорядительными и нормативными документами – изменением регламентов по предприятию.

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

Реинжиниринг бизнес-процессов, впервые рассмотренный Хэммером (Hammer 1990), предполагал отказ от существующих процессов и создание процессов, которые соответствовали бы нуждам компании в свете передовых технологий. К сожалению, для фирм оказалось трудным отказаться от существующих процессов и сотрудников.

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

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

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

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

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

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

Поэтому рекомендация специалистам заказчика – сразу планировать возможность реинжиниринга бизнес-процессов, проявить инициативу, задавать вопросы: «А как это оптимально в ERP-системе сделать?» – и быть готовыми к изменениям.

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

Очередность внедрения модулей системы

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

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

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

  • Подсистемы, выбранные для автоматизации, должны обеспечивать замкнутый контур учета (Например, чтобы продавать товары, их нужно закупать; чтобы оплачивать закупки, деньги должны поступать на расчетные счета; чтобы получать регламентированную отчетность и вести баланс – должны отражаться все учетные операции)
  •  Если какие-то блоки не автоматизируются, но результат их работы важен для целостности учета (товарные и денежные потоки, формирование бухгалтерских проводок), то необходимо предусмотреть интеграцию с существующими системами, где это все учитывается на приемлемом уровне (Если таких существующих систем нет или они не поддерживают интеграцию, нужно признать, что эти места требуют автоматизации и не могут быть вынесены на вторую очередь)
  • Для прочих, не массовых, операций можно ограничиться документами ввода финансовой и бухгалтерской учетной информации, достаточной для целостного учета без полноценной автоматизации этих бизнес-процессов в оперативном контуре системы.
  • За бортом автоматизации первой очереди можно оставить блоки, которых вообще никогда не было в бизнес-процессах компании. (Например, подсистему «Бюджетирование» хочется начать использовать, но до внедрения ERP в компании не было процессов бюджетирования, значит, этот блок можно отложить на вторую очередь. Если, конечно, это не основная цель автоматизации.)

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

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

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

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

Участники проекта внедрения

Внедрениями ERP-систем занимаются люди и именно от них зависит успех или неуспех проекта. Кто может участвовать в проекте:

  • заказчик
  • исполнитель
  • поставщик (разработчик) системы
  • спонсор проекта

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

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

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

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

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

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

Большое значение имеет коммуникации между участниками проекта.

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

Оценка сроков и бюджета проекта

Сроки и бюджет проекта

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

Проект может проходить при следующих подходах к бюджету:

  • Бюджет фиксирован (fix price) – заранее утверждается стоимость проекта, что требует серьезного и скрупулезного подхода к оценкам: учесть все, заложить риски.
  • Оплата по факту (time & material) – примерная оценка на весь проект и детальные оценки на ближайшие работы с фиксированием реальных трудозатрат по результатам сделанного.
  • Микс из двух подходов на разные блоки внутри проекта.

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

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

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

  • грубый порядок величины (row order of magnitude) – стоимостные ожидания проекта, находящегося на фазе замысла или идеи;
  • порядок величины (order of magnitude) – предположения о стоимости проекта, рассчитанные на фазе инициализации проекта, отражаемые в первичном коммерческом предложении;
  • бюджетная оценка (budget estimate) – оценка стоимости проекта, полученная на основе данных, предоставленных заказчиком после анализа исполнителем;
  • точная оценка (definitive estimate) – оценка стоимости, включаемая в бюджет при определении окончательной плановой стоимости проекта перед переходом к фазе разработки.

Таким образом, на начальной фазе проекта (инициализация проекта) дается первичная оценка «порядок величины». Точность такой оценки колеблется в диапазоне от -25 % до 75 %. То есть проект может оказаться дешевле на 1/4 или дороже на 3/4.

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

Можно ли на начальных стадиях проекта «угадать» бюджет проекта с точностью до 10–15 %? При большой практике типовых внедрений у исполнителя, когда не ожидаются какие-то значительные особенности в бизнес-процессах компании заказчика, такое возможно: можно провести аналогию с прошлыми проектами, похожими на этот. Но в какой-то момент у команды проекта случается их первый проект, и аналогов еще нет или проекты значительно различаются. Какие методы и инструменты для оценок бюджета и сроков доступны руководителю проекта?

 В случае проекта автоматизации и внедрения ERP-системы «видимый результат» может достигаться быстро, 80 %-ную готовность получить легко. Но система и проект должны быть завершены на 100 %. То есть сроки разных процентов готовности проекта нелинейные. Получить внешне рабочую систему можно просто и быстро, а вот отладить и запустить ее в полноценную работу – сложно. Это правило 80/20 – вредный трюк для мнимого соблюдения сроков, когда сдается система по списку спецификации требований, но при углубленном изучении (в работе) все начинает сыпаться и требуются значительные усилия (те самые 80 %) для доведения всего до рабочего состояния. Это нужно учитывать при оценке трудозатрат и планировании сроков, т. к. задача состоит в оценке бюджета проекта (и сроков), исходя из его завершенности на 100 %.

Для оценки трудозатрат на реализацию проекта применяются следующие методы:

  • оценка по аналогам — оценка длительности и трудоемкости по аналогам строится на данных о фактической длительности и трудоемкости ранее сделанной аналогичной работы. Этот метод часто используется при оценке длительности проекта в условиях недостатка детальной информации о проекте – например, на ранних фазах проекта. Оценка по аналогам использует историческую информацию, накапливаемую в компании-исполнителе, а также экспертные оценки сотрудников (их проектный опыт у других работодателей);
  • анализ предложений исполнителей — попросить кого-то другого оценить эти задачи. Применяется при наличии нескольких исполнителей или подрядных организаций, желающих выполнить данный объем работ. Тендерная документация, требования или иная проектная документация рассылается по исполнителям-претендентам с просьбой предоставить свои оценки стоимости и сроков выполнения данных работ.;
  • оценка «снизу вверх» —  метод оценки больших объемов работ за счет суммирования оценок, полученных для более мелких (и понятных для оценки) составляющих данной работы. Чем более подробно и точно разработана WBS проекта, тем точнее и корректнее могут быть получены стоимостные оценки по проекту.;
  • оценка «сверху вниз» — метод применяется в условиях отсутствия детальной WBS, нехватки информации о ресурсах и материалах, необходимых для реализации работ. Метод «сверху вниз» значительно менее точный по сравнению с методом «снизу вверх»;
  • экспертная оценка;
  • параметрическая оценка —  метод оценки, использующий алгоритм для вычисления стоимости или длительности на основе исторических данных и параметров проекта;
  • оценка по трем точкам (метод PERT).

Мифический человеко-час

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

Данный раздел назван по мотивам известной книги «Мифический человеко-месяц, или Как создаются программные системы» (англ. The Mythical Man-Month: Essays on Software Engineering). Книга Фредерика Брукса об управлении проектами в области разработки программного обеспечения (на основе опыта IBM OS/360) впервые была опубликована в 1975 году. В 1995 году было добавлено несколько новых глав, актуализирующих книгу.

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

Фредерик Брукс сделал вывод: «Время выполнения проекта не обратно пропорционально числу программистов, по крайней мере, по двум причинам:

  • В программировании, в отличие от, например, сбора хлопка, работа не может быть произвольно разделена на несколько независимых частей. Части проекта зависят друг от друга, и некоторые задачи можно начинать выполнять только после того, как будут закончены другие.
  • Программисты должны тратить часть времени на взаимодействие друг с другом.

Если есть N специалистов, то количество пар специалистов (для взаимодействия между собой, в нашем случае «консультант – разработчик») равно N(N–1)/2, то есть с ростом числа участников проекта затраты времени на взаимодействие растут квадратично. Поэтому начиная с какого-то N рост числа участников проектной команды замедляет выполнение проекта».

Фактический пример из реальной оценки одной проектной задачи. Есть задача на 320 ч, один разработчик делает ее за 8 недель. Привлекаем второго разработчика, задача делается за 4 недели (линейный прирост). Далее привлекаем еще специалиста, результат уже не кратный, а те же 3–4 недели. А если добавить сюда еще кого-то (явно лишнего), то срок будет такой же (3-4 недели, если не будет мешать работать остальным своим желанием «помочь») или увеличится до 6–8 недель, т. к. время на коммуникацию всех со всеми начнет расти в ущерб самой задаче.

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

В примере, что был рассмотрен выше, где 1 специалист делал задачу за 8 недель, предположим, что он уже потратил 4 недели, 4 остается, но очень хочется ускорить процесс за счет привлечения дополнительных сил. Добавим еще одного специалиста – в идеале можно было бы поделить оставшиеся 4 недели на два, но фактически экономия будет где-то 1 неделя, т. к. половину времени новый специалист будет «въезжать» в задачу, а тут еще и 50-процентная готовность, чужой код… А если привлечь двух специалистов в помощь? Тогда срок будет 9+ недель, то есть вырастет! Срок не изменится, если эти новые специалисты не будут мешать первому и он продолжит делать все сам, но если задачи поделить и «ускорять», то будут накладные расходы на интеграцию наработок и коммуникацию.

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

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

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

В своей книге Фредерик Брукс приводит также 2 способа снизить стоимость разработки программного обеспечения:

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

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

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

Давайте рассмотрим еще один интересный вопрос: сколько же «мифических» человеко-часов может «выдать» в месяц условный специалист?

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

Обычный расчет говорит нам, что 8 ч в день, 5 дней в неделю дают 40 ч в неделю. Что при 20 рабочих днях в месяц дает 160 ч, а при 23 рабочих днях – уже 184 ч. Но в среднем по году в месяце что получится?

Учтем факторы: отпуск сотрудника 4 недели, болезни условные 2 недели в год – это минус 240 ч в год, еще есть множество государственных праздников (минус еще 2 недели в году). Получается, из 52 недель в календарном году реально рабочие у сотрудника 44 недели, это 1760 ч. Делим на 12 месяцев, получаем 146 часов в условный месяц.

Именно эти 146 часов в месяц нужно планировать на проектах более 6 месяцев длительностью. Относительно 160 и 184 ч (для 20 и 23 рабочих дней в месяце) получаем разницу почти в 10 % и 20 % соответственно. Сверхурочное время и переработки (overtime) будут запасом на случаи форс-мажоров и обычно оптимистичных оценок проектов. Если же на это «святое» время закладываться сразу, то это заведомый срыв сроков или снижение качества, т. к. в режиме аврала специалисты долго в приемлемом качестве работать не смогут.

Как получить итоговый срок проекта

 В общем случае нельзя просто взять и поделить итоговое число часов, полученное оценками WBS проекта, на 8 рабочих часов в день и число специалистов в команде для получения итогового срока в рабочих днях. Но тогда как же получить календарный срок проекта, зная его трудозатраты?

Прежде чем ответить на этот вопрос, вернемся к особенностям самой оценки трудозатрат, т. к. этот вопрос не был закрыт рассмотрением методов оценок до конца. Все приведенные выше методы оценки трудозатрат, используемые при оценках бюджета проекта, показывают парадоксальную картину: все сводится к экспертным оценкам как основе для прочих моделей («снизу вверх», PERT, аналогов). А как именно думает эксперт – не формализованный процесс! Это же человек, а человеку свойственно ошибаться. Разработчики часто склонны быть оптимистами и оценивать любую задачу только со стороны разработки. А это время изучения задачи и самого процесса программирования ее реализации. Отладка, тестирование, документирование, обучение пользователей, настройка данных для рабочей базы – это все остается за бортом, если спросить: «За сколько сделаешь?» – у разработчика. Что логично: остальное же делает не он. В проектах автоматизации много работы, вообще не связанной непосредственно с разработкой. Поэтому спрашивать как эксперта нужно системного архитектора, который понимает, когда задача действительно завершается, сколько людей и каких над ней работают.

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

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

Эмпирический закон был сформулирован историком Сирилом Норткотом Паркинсоном в его сатирической статье, напечатанной в британском журнале The Economist в 1955 году и изданной позднее в книге «Закон Паркинсона» (англ. Parkinson’s Law: The Pursuit of Progress; Лондон, John Murray, 1958).

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

Все это делает график запутаннее и сложнее для восприятия, но как подход расчета внешних сроков работает.

Если руководитель проекта со стороны заказчика настаивает на максимальной детализации и контроле за ходом проектных работ, то ему можно дать доступ в такую систему Task Tracking или строить отчет из нее.

Вернемся с расчету календарного срока проекта. Необходимо учесть время отпусков специалистов (как исполнителя, так и заказчика), заложить риски на болезни (если работы попадают на ежегодные сезоны простуд). Если WBS имеет достаточную детализацию, то расчет сроков можно доверить инструментарию управления проектом, способному выстроить последовательность исполнения задач диаграммой Ганта на календарь с учетом выходных и праздничных дней. Остается аккуратно задать последовательность и связи исполнения задач, заложить время ожидания реакции со стороны заказчика (этим сложно управлять исполнителю; хотя сроки реакции и прописываются в уставе проекта, но календарно нужно иметь некий дополнительный запас). Получаем итоговый план-график.

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

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

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

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


Понравилась статья - поделись ею в соцсетях)