Целью экспресс-обследования является формирование детального и обоснованного предложения по созданию АСУП с учетом особенностей предприятия, с план-графиком проекта.

Экспресс-обследование выполняется на территории Заказчика Исполнителем на основании Договора на оказание услуг по экспресс-обследованию предприятия.

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

С каждым сотрудником предприятия интервью занимает от 1 до 3 –х часов.

В результате проведенных интервью собирается информация по бизнес-процессам, которая отражается в Отчете об экспресс-обследовании:

Оперативный учет, складская логистика, структура номенклатуры.

Финансовый учет (управленческий, регламентированный при необходимости). Казначейство.

Бюджетирование.

Долгосрочное и краткосрочное планирования продаж, производства, закупок.

Управление продажами, отгрузками, заказами клиентов, резервирование продукции, размещение заказов в производстве.

Сменно-суточное планирование производства (поцеховое), диспетчеризация.

Управление закупками.

Управление качеством.

Управление данными о продукции.

Управление персоналом, расчет заработной платы.

По каждому бизнес-процессу в отчете фиксируется:

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

Мнения сотрудников о текущей оптимальности процессов, общие пожелания пользователей к оптимизации (реорганизации) и автоматизации бизнес-процесса.

Выводы и задачи проекта.

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

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

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

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

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

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

Прочие организационные особенности предприятия.

В заключении в отчете приводится:

Выводы и задачи автоматизации по приоритетам.

Варианты архитектуры создаваемой АСУП – программные продукты и их взаимодействие.

Очередность ввода в эксплуатацию АСУП.

Предлагаемая проектная технология для каждой очереди АСУП, формы сотрудничества между сторонами и разделения ответственности.

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

Предложения по организационной структуре управления проектом со стороны Заказчика и исполнителя.

Организационные задачи Заказчика по подготовке проекта.

Экспресс-обследование выполняется одним специалистом за 10 рабочих дней, из них 5 дней – интервью (работа на территории Заказчика), 5 дней – обработка информации и формирование «Отчета об экспресс-обследовании».

Первый шаг: Экспресс-обследование 

Целью экспресс-обследования является формирование детального и обоснованного предложения по созданию АСУП с учетом особенностей предприятия, с план-графиком проекта. 

Экспресс-обследование выполняется на территории Заказчика Исполнителем на основании Договора на оказание услуг по экспресс-обследованию предприятия. 

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

С каждым сотрудником предприятия интервью занимает от 1 до 3 –х часов. 

В результате проведенных интервью собирается информация по бизнес-процессам, которая отражается в Отчете об экспресс-обследовании: 

Оперативный учет, складская логистика, структура номенклатуры. 

Финансовый учет (управленческий, регламентированный при необходимости). Казначейство. 

Бюджетирование. 

Долгосрочное и краткосрочное планирования продаж, производства, закупок. 

Управление продажами, отгрузками, заказами клиентов, резервирование продукции, размещение заказов в производстве. 

Сменно-суточное планирование производства (цеховое), диспетчеризация. 

Управление закупками. 

Управление качеством. 

Управление данными о продукции. 

Управление персоналом, расчет заработной платы. 

По каждому бизнес-процессу в отчете фиксируется: 

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

Мнения сотрудников о текущей оптимальности процессов, общие пожелания пользователей к оптимизации (реорганизации) и автоматизации бизнес-процесса. 

Выводы и задачи проекта. 

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

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

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

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

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

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

Прочие организационные особенности предприятия. 

В заключении в отчете приводится: 

Выводы и задачи автоматизации по приоритетам. 

Варианты архитектуры создаваемой АСУП – программные продукты и их взаимодействие. 

Очередность ввода в эксплуатацию АСУП. 

Предлагаемая проектная технология для каждой очереди АСУП, формы сотрудничества между сторонами и разделения ответственности. 

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

Предложения по организационной структуре управления проектом со стороны Заказчика и исполнителя. 

Организационные задачи Заказчика по подготовке проекта. 

Экспресс-обследование выполняется одним специалистом за 10 рабочих дней, из них 5 дней – интервью (работа на территории Заказчика), 5 дней – обработка информации и формирование «Отчета об экспресс-обследовании». 

Этап 1. Тестовая эксплуатация (прогон) типового решения 1С:ERP на данных Заказчика 

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

Порядок тестовой эксплуатации: 

Заказчик передает Исполнителю ограниченную выборку нормативных данных и первичных документов. 

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

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

Исполнитель консультирует Заказчика по содержанию тестового примера. 

По результатам рассмотрения Заказчиком тестового примера Исполнитель формирует документ «Отчет о результатах тестирования типового решения», который содержит: 

общую информацию о характере тестовых данных, 

заключение о необходимости доработок Типового решения и направлении этих доработок, 

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

Критерий приемки работ – согласование документа между Сторонами, утверждение Заказчиком. 

Важно! 

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

Этап 2. Функциональное моделирование 1С:ERP 

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

Состав работ на этапе ФМ: 

Обследование бизнес-процессов предприятия, подлежащих автоматизации на 1С:ERP, анализ их качества, выявление «узких мест» и требований к реинжинирингу бизнес-процессов. 

Уточнение внешних целей создания АСУП. 

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

Рабочая группа формирует требования. 

Консультанты моделируют в типовом решения на данных Заказчика. 

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

Для получения модели может потребоваться несколько итераций моделирования. 

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

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

Формирование списка необходимых доработок типового функционала 1С:ERP. 

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

В результате функционального моделирования формируется документ: 

«Отчет о результатах функционального моделирования» на очередь ERP-системы, который содержит: 

Модель бизнес-процессов «Как будет» (сценарии работы пользователей) в нотации eEPC ARIS или BPMN с привязкой к функционалу и интерфейсам, рабочим местам типового решения, при этом приводятся подробные скриншоты и текстовое описание. 

Перечень желательных доработок типового решения. 

База данных с функциональной моделью. 

Важно: 

Функциональное моделирование — это совместная работа Заказчика и Исполнителя, в непрерывном взаимодействии Сторон. 

Отчет о ФМ готовит Исполнитель, но это же и отражение труда рабочей группы Заказчика по формулировке требований, рассмотрению предложенных моделей. 

Примечания 

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

Выполнение проекта 1С:ERP по технологии SCRUM 

При использовании технологии Scrum – этапы проекта выполняются небольшими итерациями (1-2 недели, т.н. «Спринты»). После каждого спринта Заказчик и Исполнитель обсуждают результаты и корректируют (актуализируют) постановку задачи на следующий спринт. 

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

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

Первая итерация этапа «Функционального моделирования» имеет цель очертить рамки Функционального моделирования в виде списка бизнес-процессов и рамочных требований к методикам учета и управления. Также на первой итерации может быть выполнен тестовый прогон на данных Заказчика с целью определения необходимости детального моделирования. 

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

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

Этап 3. Спецификация требований 

Документ «Спецификация требований» разрабатывается на основе результатов функционального моделирования и содержит: 

Перечень возможных доработок типового решения 1С:ERP.

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

Утверждение/отклонение заказчиком каждой доработки. Заказчик может отклонить любую из доработок если согласен «подстроиться» под типовой функционал, с целью уменьшения стоимости проекта, нежелательности снятия с поддержки типового решения и так далее. 

Спецификация требований является основой для разработки Технического задания и определяет границы Технического задания. 

На основании Спецификации требований и результатов Функционального моделирования определяются сроки и стоимость разработки Технического задания. 

Этап 4. Техническое задание на доработки типового решения 1С:ERP. 

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

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

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

Этап 5. Реализация настроек и доработок, испытания 1С:ERP 

На этом этапе выполняются следующие работы: 

Доработка типового решения в соответствии с требованиями Технического задания. 

Тестирование всех доработок и компонент. 

Разработка и утверждение программы и методики испытаний (ПМИ). 

Испытания и утверждение результатов испытаний. 

Программа и методика испытаний (ПМИ) содержит описание фрагмента данных АСУП и пошаговую инструкцию по проведению испытаний с описанием получаемого результата и критериями успешности испытаний. 

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

Приемочные испытания проводятся приемочной комиссией, все замечания фиксируются в Протоколе испытаний. 

Все замечания протокола ранжируются: 

1.Явное невыполнение требований Технического задания на доработки или программные ошибки. 

2.Дополнительные требования, появившиеся у Заказчика в ходе испытаний. Реализуются как дополнительные работы.

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

Этап 6. Ввод в действие, пусконаладочные работы 1С:ERP 

На этом этапе Исполнитель и Заказчик выполняют следующие работы: 

Инсталляция рабочей базы данных, рабочих мест; 

Выполнение необходимых настроек функциональности (например, учетных политик, функциональных опций системы); 

Наладка операционного программного обеспечения и технических средств; 

Выполнение настроек прав доступа; 

Разработка методик переноса и выверки (нормализации) данных; 

Разработка, тестирование, выполнение процедур переноса данных; 

Проверка пользователями результатов переноса, выверка (проверка достоверности) и утверждение Заказчиком результатов переноса (входящих данных); 

Разработка проектов регламентов работы пользователей и администраторов (рабочих инструкций). Утверждение проектов регламентов; 

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

Обучение и тестирование ключевых пользователей и администраторов. 

Решение прочих организационных вопросов. 

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

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

Заказчик отвечает за корректность и соответствие утвержденным форматам исходных данных (подлежащих переносу). 

Исполнитель отвечает за правильность отработки утвержденной методики переноса. 

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

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

Этап 7. Опытная эксплуатация 1С:ERP 

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

На опытной эксплуатации не предъявляются требования к оперативной работе и актуальности данных в системе в режиме on-line. 

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

Цель опытной эксплуатации – в процессе практического использования ERP-системы: 

Выявить и реализовать дополнительные требования к ERP-системе, которые по тем или иным причинам не были зафиксированы в Техническом задании и модели «Как будет». 

Выявить и исправить несоответствия Техническому заданию и прочие ошибки. 

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

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

Этап опытной эксплуатации как правило пропускается если внедряется он-лайн система управления, планирования и  ввод исторических учетных данных не имеет. В этом случае после пусконаладочных работ начинается опытно-промышленная эксплуатация. 

На этапе опытной эксплуатации как правило, применяются элементы технологии Scrum. 

Этап 8. Опытно-промышленная эксплуатация 1С:ERP 

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

Актуальность данных в системе поддерживаются в режиме on-line. 

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

Отчетность пользователям для передачи руководству разрешено формировать только в ERP-системе. 

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

 Промышленная эксплуатация 1С:ERP 

Критерии перехода в промышленную эксплуатацию: 

Объем доработок в за период позволяет передать ERP-систему на сопровождение ИТ-специалистам Заказчика. 

Исполнителем выполняются работы в соответствии с гарантийными обязательствами. Осуществляются работы по устранению несоответствий системы ТЗ, выявленных при эксплуатации АС в течение установленных гарантийных сроков. 

Исполнителем выполняются разовые консультации по доработкам и развитию ERP-системы. 

Вовлечение ИТ-персонала в проект 

Большинству коммерческих компаний-внедренцев свойственно стремление выполнять проекты автоматизации своими силами, и не передавать знания о системе ИТ-службе заказчика: 

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

Это при том, что поддержка системы собственной ИТ-службой в 2-3 раза дешевле. 

  Мы не настаиваем на том, чтобы делать все самим: 

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

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

Если Заказчик решается выполнять проект внедрения нашего продукта полностью своими силами – оказываем помощь в освоении, консультируем по методикам применения продуктов. 

Если Заказчик все же решает сопровождать систему с нашим привлечением – никаких проблем, мы с готовностью это делаем! 

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

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

Предлагаем следующие пакеты услуг:

Базовая подготовка к проекту

Быстрый старт.

Базовая подготовка к проекту

Критерии выбора:

ИТ — служба предприятия имеет опыт внедрения комплексных систем автоматизации бизнеса на платформе «1С:Предприятие 8»

Функциональные модели бизнес-процессов проработаны Заказчиком, есть формализованное видение новой системы.

Проект предполагается выполнять полностью самостоятельно

Этапы работ:

1. Экспресс-обучение ИТ-службы Заказчика.

Объем работ — 12 часов (2 раб.дня).

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

2. Выезды специалистов для консультаций по использованию ПП (обязательно заранее подготовить вопросы).

Объем работ — 12 часов (2 рабочих дня).

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

Общий итог работы:

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

Быстрый старт

Критерии выбора: ИТ — специалисты предприятия имеют опыт внедрения комплексных систем автоматизации бизнеса, при этом готовы выполнить основной объем проектных работ собственными силами. Функциональная модель не сформирована, но есть требования к функциональной модели и критериальные требования к системе.

Этапы работ:

1. Экспресс-анализ бизнес процессов

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

Результат работы по двум этапам: отчет об экспресс-анализе и тестировании типового решения

3. Экспресс-обучение ИТ-службы Заказчика.

Объем работ — 12 часов (2 рабочих дня).

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

4. Консультации по подготовке системы к эксплуатации.

Объем работ — 2 выезда.

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

Общий итог работы:

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

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

Этапы работ:

1. Функциональное моделирование по одной-двум подсистемам (кроме подсистемы планирования производства). Тестирование типового решения по выбранным подсистемам — на применимость и на требуемый объем доработок.

Результат работы по этапу: отчет о функциональном моделировании — схемы и описание бизнес-процессов («как должно быть», нотация ARIS eEPC или BPMN) в привязке к типовому решению, в том числе методика использования типового решения, список функциональных разрывов, рекомендации по их устранению.

2. Обучение ИТ-службы Заказчика.

Объем работ — 24 часа (4 рабочих дня).

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

3. Консультации по подготовке системы к эксплуатации.

Объем работ — 30 рабочих дней

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

Общий итог пилотного проекта:

Схемы и описание модели процессов «Как будет».

Отлаженные на практических примерах в типовом решении бизнес-процессы.

Список функциональных разрывов.

Инструкции специалистам предприятия по подготовке входящих данных и обеспечению опытной эксплуатации.

Служба ИТ самостоятельно выполняет настройки системы, обеспечивает ввод в действие и опытную эксплуатацию

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

Владелец проекта. Утверждает требования к системе, принимает решения о финансировании работ и о приемке работ.

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

Менеджер проекта. Выполняет операционный контроль выполнения задач проекта и обеспечивает документооборот. Загрузка 3 ч в день.

Рабочая группа проекта (РГ), состоит из ключевых руководителей подразделений, входящих в рамки проекта. Загрузка 1-2 часа в день. Функции группы:

Выработка требований к системе.

Предоставление материалов для работ Исполнителю.

Оценка методических решений, анализ и согласование проектной документации.

Заключение о результатах работ.

Оперативная группа ИТ-специалистов (ОГС). Загрузка – полная, 8 часов день. Функция группы

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

Методическая помощь пользователям и эскалация вопросов на уровень Исполнителя при необходимости (обратная связь).

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

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

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

Распределение трудоемкости проектных работ (в абсолютном выражении) на стадиях:

Функциональное моделирование: Исполнитель 50%, Заказчик 50% (выработка требований, анализ и согласование результатов).

Техническое задание: Исполнитель 70%, Заказчик 30% (выработка требований, анализ и согласование результатов).

Реализация: Исполнитель 90%, Заказчик 10% (участие в испытаниях, анализ результатов испытаний).

Ввод в действие (пусконаладка): Исполнитель 30%, Заказчик 70% (ввод и выверка исходных данных).

Опытная эксплуатация: Исполнитель 20%, Заказчик 80% (работа пользователей в системе).

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

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

Постановка задачи (* — с небольшим упрощением, чтобы не перегружать статью)

Основной деятельностью предприятия является позаказное производство изделия «Балка М1».  Технология требует последовательного выполнения трех операций:

Изделия выпускаются партиями, в соответствии с заказанным клиентами количеством, в среднем партии бывают размера от 100 до 500 шт.

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

График производства нам 1C:ERP построит без проблем! Но результат размещения этапов графика - и рассчитанный в итоге срок исполнения каждого заказа - будет сильно зависеть от нюансов описания производства Балки М1 в ресурсной спецификации.

Казалось бы, что тут думать? Есть три операции — ну вот эти три составляющих процесса и надо указать в спецификации. Но указать можно по-разному! Итак…

Варианты решения

Вариант 1. Очевидный, но невероятный

В ресурсной спецификации на Балку М1 создаем единственный этап, на котором в соответствии с таблицей предусмотрим загрузку Фрезеровального станка, затем Сверлильного станка, затем опять Фрезеровального станка.

Однако, к сожалению, такую спецификацию будет невозможно использовать, т.к. 1C:ERP не позволит на одном этапе нормировать в нескольких строках загрузку одного Вида рабочих центров (ВРЦ):

Поэтому такой вариант является технически неприменимым.

Вариант 2. С допущением (ТОС)

В соответствии с Теорией Ограничений Систем (ТОС), следование принципам которой, особенно в ранних версиях, декларировалось методологами 1C:ERP – можно выделять в описании производственного процесса только ключевые рабочие центры, пренебрегая недозагруженными рабочими центрами. Таким образом, мы нормируем загрузку только на потенциальных узких местах производства, а короткие операции на относительно свободных РЦ при планировании графика можно не описывать вообще, либо выделить на них фиксированный буфер.

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

Как определить, согласно ТОС, какой именно ВРЦ будет ключевым? Решающее значение для определения пропускной способности имеет коэффициент загруженности вида рабочих центров: отношение общего доступного времени данного вида оборудования к общему времени назначаемых на него операций.

В приведенном примере исходим из данных о том, что парк оборудования в цехе предоставляет примерно сопоставимый объем доступности для фрезерного и для сверлильного станка. А загрузка фрезерного станка, согласно таблице, при этом многократно превышает загрузку сверлильного станка. Таким образом, фрезерный станок в данном контексте является «узким местом» производства. На рассматриваемом предприятии выпускаются и другие изделия, кроме Балки М1, но при их выпуске загрузка сверлильного станка тоже незначительна или отсутствует. Поэтому на этом проекте было принято решение о допустимости заменить в спецификации работы по сверлению на буферное время.

Вот как при этом будет выглядеть график производства для партии в 100 изделий:

Вариант 3. Поэтапный

Можно пойти следующим путем: разделить производственный процесс на два этапа; или даже на три, по одному этапу на каждую операцию.

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

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

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

График производства на партию в 100 шт.:

Важно отметить, что если рассмотреть немного отличающуюся технологию выпуска другого изделия (например, Балка М2), в которой нет операций на одинаковых ВРЦ, то корректность планирования в варианте с разнесением операций на разные этапы уже будет сомнительной! С учетом размера партии (100-500шт) график этапов в 1C:ERP окажется сильно растянут относительно того, как работы выполняются в действительности.

Допустим, для Балки М2 вместо заключительной операции фрезерования выполняется проточка на токарном станке. Для такого техпроцесса 1C:ERP предложит график, аналогичный приведенному выше, с началом каждого следующего этапа после завершения предыдущего этапа.

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

График, формируемый программой, в данном случае можно сделать реалистичнее, если разбить запуск на множество более мелких партий, хоть до 1 изделия в партии, 1С:ERP это вполне позволяет.

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

Поэтому для технологии «Балка М2» правильнее будет использовать нормирование работ ВРЦ в соответствии с обозначенными выше Вариантом 1 (для разных ВРЦ на одном этапе он вполне подходит) или Вариантом 2.

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

Примечание. В кейсе использовалась версия 1С:ERP 2.4.

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

Приведем примеры из практики двух наших клиентов, ситуации которых оказались схожи между собой. На предприятиях ранее внедрялось 1C: ERP. Несмотря на то, что в обоих случаях заказчик до нас привлекал не очень опытных консультантов, не имеющих статуса «1С:Центр ERP», тем не менее начинались проекты быстро и руководство было довольно ходом работ. Но затем внедрение зашло в тупик: доработки программы продолжались и продолжались, плановый бюджет проекта давно был превышен, а промышленная эксплуатация никак не начиналась. Представители этих предприятий обратились за советом к экспертам ИТРП.

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

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

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

Исполнители проекта пытались следовать технологии, например, были предусмотрены документы «Устав проекта», «Журнал рисков», «Журнал запросов на изменения» и пр. Однако содержание этих документов оказалось по большей части шаблонным, их заполняли методом «копи-паст», а затем и вовсе забросили.

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

В данном случае, отсутствие ориентиров способствовало тому, что через некоторое время проект сорвался в фрагментарные и необоснованные доработки.  Значит ли это, что без правильного Устава проекта результата в итоге не будет? Нет, конечно )) Можно внедрять и вообще без Устава. Однако, когда цели и приоритеты определены документально, то это способствует удержанию проекта в заданных рамках.

Функциональное моделирование выполнялось на скорую руку, крайне поверхностно.

Отчет по аудиту проектов «ААА» и «ВВВ», стр.5: При функциональном моделировании выявлено 9 и 12 функциональных разрывов. Отметим, что на типовых проектах ИТРП при тщательном моделировании в контексте тех же бизнес-процессов выявляется обычно намного больше отклонений от типовых функций. Таким образом, можно предполагать либо очень упрощенные бизнес-процессы, либо (более вероятно) чрезмерно поверхностное моделирование. Значительная часть функций, входящих в бизнес-процесс, при моделировании была пропущена, в том числе: <…>.

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

Далее на рассматриваемых проектах было составлено ТЗ по основным функциональным разрывам. ТЗ составлено на достаточно неплохом техническом уровне, замечаний нет. Доработки по первым разделам ТЗ выполнены качественно.  Но выполненных доработок оказалось недостаточно, т.к. при попытке начать опытную эксплуатацию стало дополнительно выявляться множество функциональных разрывов, в том числе значительных. И эти разрывы начали затыкать как придется, точнее – по принципу «как можно быстрее». Исполнители проявили излишний пиетет к традициям предприятия по сложившимся бизнес-процессам и по имеющимся формам бумажных документов, начали реализовывать в системе все пожелания всех пользователей в порядке их поступления, без какого-либо анализа этих запросов.

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

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

Например, сначала в программе реализовали функцию «А» в подсистеме управления запасами. Затем вдруг выяснилось, что с учетом специфики управления потоками потребностей надо еще сделать «Б», а для этого придется полностью переделывать «А». А после этого пользователи потребовали запрограммировать функцию «В», причем реализовав «В» оказалось, что «А» и «Б» уже будут вообще не нужны. И так далее…

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

Кроме того, экспертный анализ показал, что по нескольким ЧТЗ целесообразность их реализации вообще крайне сомнительна, т.к. не способствует значимым улучшениям в бизнес-процессах.

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

Другой источник проблемных доработок: пользователи потребовали «сделать в программе так, как привыкли работать раньше».

Например, для поступления от поставщика необходимых производству материалов к необходимому сроку — в существующем бизнес-процессе производство передает заявки в ОМТС, затем начальник снабжения перегруппировывает заявки по критериям длительности поставки в отдельные документы — задания менеджерам, затем менеджеры запрашивают счета у поставщиков и контролируют по каждому счету объем и срок фактического исполнения поставки. Всю эту модель работы описали в ЧТЗ и начали дорабатывать под нее 1C:ERP. Причем программистам пришлось затронуть типовые объекты, а это сильно затрудняет обновление системы!

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

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

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

Успехов на ваших проектах!

В этой статье: ответ на часто возникающий в начале проекта вопрос о последовательности проектных очередей. То есть о том, в каком порядке внедрять функциональные подсистемы 1C:ERP, с учетом приоритетов предприятия.

Исходная ситуация: на стартующем проекте, реализуя стратегию предприятия-заказчика, намечена следующая последовательность внедрения очередей 1C:ERP (по порядку убывания приоритета):

Оперативный учет ТМЦ

Планирование производства

Регламентированный учет (в 1С:ERP)

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

В настоящее время регламентированный учет ведется в программе «1С:Бухгалтерия». Оперативный учет автоматизирован фрагментировано в 1С:УПП, планирование производства по сути не автоматизировано. Работает отлаженная процедура выгрузки данных первичных документов из 1С:УПП в 1С:Бухгалтерию.

Вопрос

Какой вариант выбрать:

А) 1С:УПП и 1С:ERP работают параллельно, пока регламентированный учет не переведен на 1С:ERP. Таким образом, частично дублирующиеся системы будут функционировать одновременно до конца 3-й очереди.

Б) Отказаться от оперативного учета в 1С:УПП и реализовать временную выгрузку из 1С:ERP (оперативный учет) в 1С:Бухгалтерию в ходе 1-й очереди внедрения.

Каждый вариант имеет свои минусы:

А) Поскольку оперативный учет по-прежнему ведется в 1С:УПП, навряд ли можно ожидать, что данные оперативного учета в 1С:ERP будут достоверны.

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

Новая учетная система будет являться «подчиненной», в ней дублируются операции, совершенные по факту и внесенные ранее в «ведущую» систему.

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

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

Почему так?

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

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

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

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

Зачастую, нетривиального функционала, при том, что этот функционал – временный.

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

Кстати, если оперативный учет будет основан на действующей системе, не так-то просто будет добиться, чтобы часть бизнес-процессов (планирование) были встроены в новую систему, при том что часть процессов (учет) остаются в старой системе!

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

Посмотрим, что будет, если переставить очереди 2 и 3. Сначала запустим с 1 января учетный блок в полном объеме – оперативный и регламентированный учет. А далее, когда будет обеспечена устойчивая работа системы учета, запускается  3-я очередь – планирование производства.

Одномоментно происходит отказ и от старой системы оперативного учета 1С:УПП, и от старой системы регламентированного учета (1С:Бухгалтерия). Таким образом, не требуется ведение параллельных учетов, не требуется разработка временных функционалов обмена.

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

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

Предлагаемая последовательность очередей на рассматриваемом проекте:

Оперативный учет ТМЦ – с 1 января.

Регламентированный учет (в 1С:ERP) – с 1 января

Планирование производства – по мере стабилизации учетного блока

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

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

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

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

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

— Давайте функциональное моделирование вот этих бизнес-процессов сделаете вы, а вот по этим бизнес-процессам моделирование пусть выполнят мои системные аналитики из ИТ-отдела!

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

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

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

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

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

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

По типовой технологии подготовка и выполнение испытаний являются обязательными совместными работами заказчика и исполнителя (исполнитель в основном выполняет методическую поддержку испытаний, заказчик при этом контролирует результат). При выполнении тестирования и испытаний только сотрудниками автоматизируемого предприятия, без участия экспертов ИТРП – действительно, удалось примерно на 14% сократить стоимость соответствующего этапа работ. Но длительность этого этапа очень сильно увеличилась!

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

Этап реализации доработок 1C:ERP на данном проекте в цифрах: на программирование в план-графике было выделено 20 рабочих дней, тестирование и испытания по типовой технологии (совместное участие) планировалось на 5 рабочих дней, по факту тестирование и испытания при их выполнении самостоятельно только штатными сотрудниками заказчика заняли 25 рабочих дней. То есть первоначальная длительность этапа в 25 раб. дней (20+5) – увеличилась почти вдвое, до 45 раб. дней (20+25).

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

Известно, что в типовом решении 1С:ERP реализована передовая методика планирования производства. Алгоритмы планирования 1С:ERP при этом частично опираются на классические методики: MRP, APS, ТОС (ББВ). Можно ли сказать, что в 1С:ERP вошли лучшие концепции из этих теоретических моделей?

Попробуем ответить на этот вопрос и для начала рассмотрим вкратце суть алгоритма межцехового планирования 1С:ERP. В этой статье разбираем именно так называемый межцеховой уровень управления «главного диспетчера», внутрицеховое оперативное управление производством здесь не затрагиваем.

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

Раньше желаемой даты запуска программе запрещено планировать выполнение графика по заказу.

Выпуск изделия должен быть запланирован не позже желаемой даты выпуска (по сути, это дата, желаемая клиентом).

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

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

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

ВРЦ могут загружаться последовательно (то есть сначала будет распределено по интервалам время работы одного ВРЦ, затем второго, третьего и т.д),

ВРЦ можно загружать одновременно (в каждом интервале будет запланировано одинаковое время работы для каждого ВРЦ),

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

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

После этого планирование осуществляется вправо или влево в соответствии с выбранным направлением размещения выпуска, до полного размещения необходимого времени работы оборудования по этапу планируемого заказа. При этом этап захватывает время работы ВРЦ, указанных в его спецификации, и это захваченное время становится недоступным для всех последующих менее приоритетных заказов.

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

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

Если раньше — все нормально.

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

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

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

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

Какие выводы можно сделать о достоинствах такой модели планирования, относительно классических методик?

С описанием классических определений и теоретических концепций планирования при желании вы можете предварительно ознакомиться в нашей отдельной статье …

Реализован ли в 1С:ERP алгоритм APS?

Очевидно, что алгоритм 1C:ERP похож на APS —планирование слева-направо и справа-налево, расчет даты запуска и даты выпуска, захват времени работы ВРЦ в процессе планирования, планирование заказов поочередно с поочередным захватом мощностей. Однако пооперационное планирование с расписанием операций по конкретным рабочим центрам на межцеховом уровне не выполняется, что делает такой график приблизительным. В этом есть и свой плюс — система не требует точных пооперационных нормативов для межцехового управления!

Приближенность такого графика обусловлена следующим допущением: если на этап производства требуется время работы ВРЦ, то это время не привязывается к производственным операциям, не учитываются взаимосвязи между операциями (т.е последовательности выполнения) и их распределение на рабочие центры —  при планировании на межцеховом уровне 1С:ERP об этом ничего не знает!

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

Важно, что загрузка ВРЦ  в данном случае учитывается именно в процессе планирования и непосредственно влияет на ход планирования (в MRP-системах загрузка мощностей тоже будет учтена, но уже постфактум – как констатация: получился ли план выполнимым или нет).

Можно считать, что такой расчет не позволит уплотнить загрузку ВРЦ настолько, насколько это позволяет APS. Поэтому может потребоваться дополнительная буферизация, искусственное занижение доступного фонда работы и не 100% загрузка оборудования в графике. И в этом смысле методика 1С:ERP ближе к MRP-системам.

Зато 1С:ERP не требует высокой точности нормативных данных, как того требует системы APS, а это очень важное преимущество. Без точных нормативных данных построить точный пооперационный график производства не получится, но он будет в любом случае точнее, чем график, формируемый MRP-системой. Аналогично APS-системе, 1С:ERP строит приблизительный график совокупной загрузки мощностей, отдавая все полномочия по его исполнению и планированию операций диспетчеру цеха.

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

Итак, можно утверждать, что алгоритм планирования производства 1С:ERP — нечто «среднее» между MRP и APS, компромиссный вариант.

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

Реализован ли в 1С:ERP алгоритм MRP/CRP/RCCP?

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

В первом случае на выполнение этапа будет выделяться фиксированное время, указываемое в спецификации и не зависящее от количества обрабатываемых изделий по заказу. Для этого в спецификации этапа надо снять флажок «Использовать виды рабочих центров». В этом случае мы получаем планирование по алгоритму MRP. Причем это будет достаточно усеченный MRP, поскольку длительность этапов распланированного заказа никак не зависит от количества готовых изделий в заказе. Например, на выполнение заказа из 1 шт. и 1000 шт. программа отведет 3 дня, согласно суммарной длительности этапов заказа. Также важно понимать, что расчет сроков обеспечения материалами осуществляется до процедуры расчета графика на основе данных обеспечения в цепочках поставок.

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

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

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

Итак, при настройке 1С:ERP в режиме MRP получается совсем приблизительный график. Он менее точен, чем график, рассчитанный по полному алгоритму MRP, но дает общее представление о том, какие изделия и в какое время сдавать.

Реализован ли в 1С:ERP алгоритм ББВ (ТОС)?

Как отмечалось выше, в 1С:ERP можно использовать варианты:

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

Указать, что этап производства выполняется фиксированное время для любого количества изделий и не захватывает время работы ВРЦ.

Если в производстве есть ярко выраженный узкий ВРЦ, то можно поступить проще: в спецификации, которая задействует этот «узкий» ВРЦ, достаточно указать потребное время работы этого ВРЦ (вариант 1), а в остальных спецификациях на полуфабрикаты в структуре продукта использовать фиксированное время выполнения этапа (вариант 2).

В результате:

Узкий ВРЦ будет «барабаном».

Цепочка спецификаций перед барабаном с фиксированным временем выполнения будет «веревкой».

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

Суммарное фиксированное (!) время выполнения цепочки спецификаций после барабана будет «завершающим буфером».

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

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

Получаем ББВ в чистом виде!

У этой методики возможны следующие расширения:

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

предварительный перед ВРЦ1

промежуточный между ВРЦ1 и ВРЦ2

завершающий после ВРЦ2

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

Пример. Нормативное время загрузки ВРЦ на этапе составляет10 часов, а оператора, обслуживающего этот ВРЦ — 5 часов. Это значит, что 2 станка работают параллельно по 10 часов, а один оператор работает 10 часов на двух станках одновременно (так называемый «многостаночник»). В спецификации этапа можно указать два и более ВРЦ с разными потребными временами для выполнения спецификации. Получаем несколько параллельно работающих «барабанов» в цехе (например, станок +оператор), работу которых программа будет загружать, исходя из доступного фонда их рабочего времени.

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

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

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

Получается, что правки спецификаций приходится выполнять не из-за изменения технологии изготовления отдельного продукта, а из-за изменения ассортимента выпускаемой продукции, что нелогично и неудобно. При изменении «узкого ВРЦ» необходимо зайти во все спецификации и выяснить у технологов (или извлечь из PDM-системы) операционные времена ВРЦ, которые теперь стали узкими. После этого операционные времена (потребности во времени работы) ВРЦ , которые стали «узкими», надо вписать, а потребности во времени работы ВРЦ, которые перестали быть узкими — удалить.

Решение проблемы миграции «узких мест» содержится в дополнении ИТРП VIP:1C ERP.

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

Заключение

В этой статье мы постарались изложить основные моменты методик, опуская все подробности. Разумеется, в APS, MRP и ББВ существует множество нюансов, о которых можно прочитать в специальной литературе. Мы не ставили целью детально описать функционал планирования 1C:ERP, а лишь хотели показать, насколько близка реализация планирования производства 1С:ERP к классическим методикам.

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

полностью реализована методика ББВ, с некоторыми ее модификациями;

реализована простая модель MRP (длительность этапа не зависит от размера заказа);

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

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

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

На встрече по обсуждению потенциального проекта внедрения 1С:ERP руководитель предприятия-заказчика поднял интересную тему:

— Мы ранее еще обсуждали задачи нашего проекта с несколькими интеграторами и партнерами 1С. Понятно, что точную оценку стоимости полного внедрения заранее никто не зафиксирует, но приблизительный диапазон называют – и он у разных исполнителей очень сильно отличается! А один интегратор рассказал, что они при определении предварительного бюджета в первую очередь считают количество автоматизируемых рабочих мест, т.е. так называемые АРМы. И затем умножают количество на нормативную цену одного АРМ, получая общую стоимость всего внедрения. Вам знаком такой подход к оценке?

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

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

По опросам партнеров, при внедрении 1С:ERP на ряде предприятий действительно наблюдается линейная зависимость между общей стоимостью проекта и количеством рабочих мест.  А если зависимость линейна, то значит можно говорить о наличии некой статистически-постоянной цены 1 АРМ!  И по накопленной по партнерским внедрениям статистике эта цена составляет примерно 50000-100000 руб за одно рабочее место, в зависимости от исполнителя (в т.ч в регионах, например, цены ниже).

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

Казалось бы, все просто: если в программе предполагается работа, например, 40 пользователей, то внедрить 1С:ERP будет стоить по верхней оценке 40 х 100000 = 4 млн.руб, правильно? Но известно ли, когда расчет по этой цене работает, а когда – нет? То есть, при каких условиях стоимость проекта по факту окажется близка к сумме 100000 руб х Количество АРМ?

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

складской учет

продажи

закупки

расчет себестоимости

регламентированный учет

зарплата и кадры

казначейство.

И важно, что внедрений 1С: ERP именно с этими подсистемами – большинство среди всех внедрений по рынку.  А среди проектов фирмы ИТРП наоборот, не менее половины наших клиентов (а скорее более) требуют автоматизацию не только перечисленных учетных функций, но и более сложных задач: объемное планирование, производственное планирование, оперативное управление производством.

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

Проекты автоматизации на 1С:ERP с внедрением «сложных» подсистем обычно дороже. И в определении бюджета таких проектов уже нет линейной взаимосвязи между количеством рабочих мест и некой стандартной ценой за 1 АРМ. Разброс (т.е отклонение) от средней цены АРМ по разным проектам настолько большое, что метод оценки «Количество х Цена АРМ» становится неприменимым, ошибка может быть в разы.

Почему так? Объяснение лежит на поверхности.

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

А вот с автоматизацией задач планирования и управления производством дело обстоит сложнее. В этих бизнес-процессах — больше всего отраслевой специфики. Да что там говорить, специфика не только отраслевая, практически на каждом предприятии есть свои уникальные и принципиальные особенности в планировании графика производства, в управлении цепочками потребностей и поставок, в диспетчировании производства и т.д.  В большинстве случаев выполнение упомянутых функций не формализовано и требует от консультантов дополнительной исследовательской работы: «Точно ли сейчас это делается вот так?  И не возникает нестыковок со смежными функциями?  Ого, вот этот бизнес-процесс при автоматизации по всей видимости лучше делать по-другому?». Далее, после уточнения всех этих вопросов и функционального моделирования – уточняется объем доработок, причем нередко он значительный.

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

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

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

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

Автор: Мартынов Дмитрий. Кодер Лоджик.

Уже общим местом стало высказывание, что внедрение ERP-системы меняет бизнес процессы. Что ни статья или высказывание ИТ-эксперта, обязательно «невозможно внедрение системы без изменения процессов» или «изменение процессов наверняка произойдет, и это надо планировать заранее». Не цитирую источники, ибо имя им легион. Тут еще важно то, о чем эксперты обычно не говорят: процесс изменяется непредсказуемо. Ну кто же признается в том, что не контролирует происходящее, так можно и контракта лишиться. Одна показательная история многое объясняет.

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

Так вот… Одна замечательная компания в процессе роста из малого предприятия в средние затеяла внедрение ИТ-системы для учета и управления.

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

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

Мог ли в первоначальное ТЗ попасть сброс резервов? Ну если там не было резервов, то откуда взяться сбросу. Может быть, консультанты сплоховали? Да нет уж, письмо, разъясняющее преимущества резервирования, было… Хотя в конце все получилось не так, как описывалось в письме. Можно ли было все предсказать заранее? Теоретически… Теоретически при современном развитии технологий человечество давно должно было иметь колонии на Марсе, практически этого не происходит, увы. И тут похожая история.

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

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

Почему же все так непредсказуемо?

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

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

Меня всегда забавляет задание на ИТ-систему, которое начинается с задач планирования. Давайте начнем с учета, ведь планирование будет эффективным, если оно будет опираться на достоверные данные. А в процессе отладки учета может вылезти столько изменений к первоначальному заданию, что упомянутые в нем идеи планирования будут оторваны от реальности.

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

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

В области ERP-систем наиболее используемым методом управления стал Scrum.

Здесь накоплено большое количество практики и есть много хорошего материала.

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

Б. Затем обязательно следует прочитать «Scrum и XP: заметки с передовой» Хенрик Книберг. Тут много реальной практики: проблем и решений.

Достоинство методики, возможность выстроить и планировать процесс при сильной изменяемости задания и среды. Недостатка я вижу два.

Стандарт scrum подразумевает очень короткие спринты (этапы), которые не позволяют на проекте ERP проконтролировать промежуточный результат.

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

Меньшая определенность стоимости проекта.

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

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

Заказчики часто требуют фиксированный бюджет от исполнителей до начала ИТ-проекта. Эта логика понятна. Заказчику нужно «заложить» бюджет на очередной год, а также понимать в какие деньги ему обойдется система. Но поставим себя на место исполнителей — мы сталкиваемся с ситуацией «фиксированный бюджет за нефиксированный результат при неизвестных условиях работы»…

Требования к системе формируются зачастую на уровне «Система должна планировать и диспетчировать». Что именно под этим подразумевается, не уточняется. Неизвестно какое будет содействие Заказчика и какую часть работ он сможет взять на себя — реально, а не по обещаниям. Но уже идет разговор о фиксированном бюджете.

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

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

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

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

Расчет сметы для выполнения проектов автоматизации — задача более сложная и формализации практически не поддающаяся. Возможны лишь экспертные оценки.

Согласно статистике, бюджет не выдерживается для 80% ERP-проектов автоматизации.

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

тендер

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

Если демпингование происходит по тарифной ставке консультантов за час, то это более приемлемый вариант. Но надо понимать, что стоять с секундомером рядом с консультантами пока они оказывают свои услуги — навряд ли кто будет, а нормативов на работы консультантов и программистов (например 10 строк кода за 5 мин, 5 консультаций за час) :) не существует. Кроме того чем ниже в результате торга опущена тарифная ставка, тем менее квалифицированные консультанты будут предоставлены исполнителем. А ведь от опыта и знаний консультантов успех проекта зависит кардинально!

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

Причина изменения бюджета в процессе выполнения проекта проста.

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

Например:

Трудоемкость проектирования доработок становится известной только после этапа «Функциональное моделирование» и утверждения заказчиком списка доработок «коробочного» функционала которые надлежит выполнить. Какие-то доработки могут быть отвергнуты заказчиком из-за их цены.

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

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

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

Каким образом можно оформить договорные отношения, чтобы не переплатить за риски, а с другой стороны — заплатить за проект согласно фактической трудоемкости?

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

Решения:

А) Если надо фиксировать бюджет:

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

Б) Если надо фиксировать результат:

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

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

AGILE/SCRUM — В ЧЕМ СУТЬ И В ЧЕМ ВЫГОДА ДЛЯ ЗАКАЗЧИКА ПРИ ВЫПОЛНЕНИИ ПРОЕКТОВ?
Лисин Н. Г.

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

Agile, Scrum, Kanban – эти слова уже успели примелькаться всем, кто имеет какое-либо отношение к разработке продуктов, бизнес-процессам, организации труда. Многие считают, что за этими технологиями будущее. Но, что интересно, немногие могут объяснить различия между этими понятиями, например, ответить на вопрос о Scrum и Agile: разница существует и в чем она заключается?».

Итак, сперва определимся с методологическим аппаратом:

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

Scrum – одна из методологий в рамках Agile. В основе данной методологии лежат «спринты» — короткие жестко фиксированные по времени итерации, в рамках которых как исполнитель так и заказчик выполняются определенный набор задач. Подробнее о Scrum, разнице Scrum и Agile читайте здесь.

Kanban – система, которая предусматривает организацию разработки/труда/производства/снабжения в соответствии с принципом Just In Time (или точно в срок). В основе Kanban лежит производственная и снабженческая система Toyota, которая во второй половине XX века чуть было не уничтожила весь американский автопром.  Подробнее о Kanban читайте здесь.

Основными ценностями в концепции Scrum объявлены коммуникация и готовность к изменениям, а не жесткое следование первоначальному плану. Когда же Scrum может принести только пользу, а когда  — вред?

Чтобы разобраться, рассмотрим сначала традиционную «жесткую» технологию, основанную на так называемом «договоре подряда» (гл. 37 ГК РФ).

Жесткая подрядная технология
Суть подряда, определенная в ГК, очень проста. Заказчик заказывает и четко определяет в спецификации к договору, что именно он хочет получить. В договоре четко фиксируется стоимость и срок. Заказчик передает исполнителю материалы, пригодные для обработки. Исполнитель проверяет материалы, и если они непригодны, то немедленно сообщает об этом Заказчику и останавливает работы. Заказчик обязан оказывать Исполнителю содействие в процессе работ. Если Исполнитель не уложился в срок, или предоставил настолько некачественный результат, что можно предположить недостижение результата как такового — Заказчик имеет право расторгнуть договор и потребовать возврат аванса в полном размере. Если же результат достигнут, то Заказчик принимает работы, подписывает акт выполненных работ, оплачивает работу.

Договор

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

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

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

Наивные Заказчики принимают бюджет, полагая, что и сроки, и бюджеты будут соблюдаться. При этом, согласно договору, этапы работ в любом случае закрываются актами и оплачиваются отдельно, чуть ли не помесячно. Не исключено, что через несколько месяцев выяснится, что бюджет необходимо увеличить в 2-3 раза (мол, требования к системе изменились, а «мы об этом не договаривались, в ТЗ этого нет!»). Не хотите — до свидания. Но такие неприятные ситуации — тема для другой статьи.

Бюджет

Основной недостаток жесткой технологии — существенные ограничения гибкости в требованиях и решениях, в условиях выполнения работ, ограничения гибкости участия Заказчика в процессе выполнения этапа. Такая гибкость в ходе выполнения работ крайне важна, так как в начале каждого этапа детальные, исчерпывающие, точные требования и организационные условия  сформулировать затруднительно – высока степень неопределенности системы. Интеграторы-исполнители часто говорят: «Клиент сам не знает, чего хочет»… Совсем тупиковые ситуации возникают, когда клиент — который не знает, чего хочет — требует сделать систему «под ключ».

^43633C784AB5D84BD442AB161BB5804C2EE7527D3C3CE9E369^pimgpsh_fullsize_distr

Но это не Заказчик виноват… это всего-навсего специфика таких проектов.

Поскольку сроки и бюджеты определяются в начале каждого этапа, любые корректировки требований к системе со стороны Заказчика, а также любые изменения условий в процессе выполнения работ на этапе (например, объем участия и содействия со стороны Заказчика) могут создать дополнительную трудоемкость для Исполнителя, что потребует пересмотра бюджета и сроков. Но пересмотр бюджетов и сроков — потенциально конфликтная ситуация!

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

Для повышения гибкости — в бюджет и сроки закладываются риски. Кроме того, опытные Исполнители предусматривают и прописывают процедуру «Управления изменениями», согласно которой в конечном итоге все изменения первоначальных требований проходят через процедуры инициирования и оценки.

Стоимость рисков Исполнителя, отраженных в бюджете проекта, в подобных работах может достигать более 50% от стоимости этапа. Другими словами, Исполнитель продает заказчику не только результат работ, но и свои риски. Если риски не реализуются, стоимость работ для Заказчика оказывается завышенной относительно реальной трудоемкости этих работ, а Исполнитель получает дополнительную прибыль. Бывает и наоборот — реализовываются незапланированные риски сверх бюджета, в результате чего Исполнитель оказывается в убытке.

Таким образом, подрядная технология ограничивает гибкость Заказчика в изменении требований, условий работы и степени своего участия, когда работы уже начаты, и «корабль отошел от берега». Необходима процедура управления изменениями… но нет гарантии, что эта процедура сможет предусмотреть все ситуации.

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

БесполезнаяРабота

Почему же Заказчики, как правило, требуют, чтобы внедрение сложных систем выполнялось по договорам подряда? Ответ прост:

Другие способы разделения ответственности для Заказчика менее комфортны. В договоре Заказчик заказывает, а Исполнитель — исполняет, эта логика порождает разделение ответственности сторон за проект, удобное для Заказчика.
Другие (не подрядные) технологии  требуют большей ответственности со стороны заказчика.
Почему Исполнители охотно соглашаются на подряд?

Чтобы обеспечить гибкость в требованиях, Исполнители закладывают в фиксированную стоимость проекта  риски. Если риски не реализуются, Заказчик переплачивает.
Требования к результату согласуются «на берегу», а значит, Заказчик опять лишается гибкости, а Исполнитель получает возможность не делать нужный Заказчику функционал, ссылаясь на то, что «в ТЗ этого нет». Так работать спокойнее: зафиксировал требования и «вперед»…
Знакомая ситуация?

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

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

Но гибкость требований и подряд – антагонизмы!

Гибкая технология (Scrum)
scrum

Смысл концепции Scrum в том, что каждый этап работ разбивают на короткие итерации фиксированной длительности (от 1-й недели до месяца). В начале каждой итерации определяют задачи сторон — Заказчика и Исполнителя — только на данную итерацию. В процессе итерации (в терминологии Scrum – «Спринт») изменения в задачах Сторон, требованиях и условиях выполнения работ не допускаются. По завершении итерации Стороны анализируют результаты и ставят задачи на следующую итерацию; и при этом уже допускается изменять условия выполнения работ.

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

project

Такие работы удобнее выполнять по договору оказания услуг (ГК РФ, глава 39), а не по подрядному договору. Преимущество гибкой технологии:

За счет того, что итерации намного короче, чем весь этап работ, достигается гораздо большая гибкость в принятии решений и управлении изменениями в ходе работ. Между итерациями Заказчик не ограничен в принятии организационных решений, изменении рамок проекта и так далее. Очевидно, что стороны движутся к результату более коротким путем, чем при подряде, поскольку могут непрерывно вносить изменения в проект.
Исключаются конфликтные ситуации  по причине изменений, так как в центр  такой технологии поставлена возможность изменения. Если при подряде изменение — это неприятное отклонение, требующее разборок и выяснения, кто кому должен, то в Scrum изменения — это суть и составляющая процесса.
Тарификация итераций тоже может быть гибкой – либо оплата  производится по фактической трудоемкости  (согласно почасовой ставке работы сотрудника); либо стоимость итерации фиксируется в начале итерации, исходя из прогноза ее трудоемкости. В результате, Заказчик оплачивает только фактическую трудоемкость и не переплачивает за риски.
Прогноз стоимости каждой итерации выполняется достаточно просто по почасовому тарифу (если известно количество сотрудников Исполнителя,  планируемых на итерацию с полной загрузкой).

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

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

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

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

Слон

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

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

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

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

 Такая ситуация характерна не только для ИТ-проектов. При ремонте квартиры, строительстве дома, и любом проекте, когда сложно четко формализовать окончательный результат, Заказчик может начать контролировать непрерывно каждый мелкий этап и вносить корректировки в изначальную постановку задачи. Это приводит Исполнителя в замешательство, т.к. сроки и трудоемкость работы неконтролируемо растут, а бюджет проекта не меняется. Исполнитель начинает думать, что «Заказчик не знает, что хочет», это потенциально конфликтная ситуация. На самом деле, Заказчик и не может знать, что хочет — это вполне нормально. Что он хочет, он начинает понимать только после того как увидит, что получается по факту — только после очередной итерации работ. Это Scrum.

На ИТ проекте «сваливание» проявляется следующим образом.

Как правило это происходит на этапе реализации (кодирования). Как только Заказчик просит показывать промежуточные результаты, и начинает их принимать, не дожидаясь предъявления всего объема работ на испытания, ждите переход по факту в Scrum. Приемка Заказчиком уже первой итерации работ скорее всего повлечет за собой частичный пересмотр Заказчиком всего технического задания, а это уже Sсrum. Разумеется, для конечного результата и удовлетворения Заказчика это благо. А пересмотр ТЗ — это изменение трудоемкости, обычно в большую сторону. И если не заключить дополнительное соглашение на увеличение стоимости, то ущемляются интересы Исполнителя. А это конфликтная ситуация.

Возникает вопрос — не проще ли изначально договориться работать по Scrum? Ведь справедливая оплата работ должна соответствовать фактической трудоемкости, которая при «сваливании» в Scrum не поддается точному расчету!

Что же получается? Заказчик может отрицать Scrum при заключении договора, но потом фактически заставить Исполнителя работать по Scrum. В рамках фиксированного срока и   бюджета. И не забываем, что просрочка срока сдачи работ (из-за постоянного внесения Заказчиком мелких корректировок в задачу) грозит Исполнителю серьезной ответственностью, т.к. Исполнитель отвечает за срок сдачи работ. Неисполнение срока дает право Заказчику предъявлять обоснованные претензии. Более того, Заказчик может упрекать Исполнителя в недостаточном профессионализме, т.к. Заказчик склонен часто свои корректировки в постановку Задачи расценивать как свои требования исправить недостатки…

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

Много говорят о том, что при внедрении ERP-класса недостаточно просто разработать Техническое задание (ТЗ), как это делается при внедрении систем учета хозопераций, а надо детально обследовать автоматизируемые бизнес-процессы предприятия, очень глубоко «встроиться» в жизнь пользователей и предприятия, выполнить моделирование бизнес-процессов в ERP-системе вместе с Заказчиком, двигаться итерациями в виде тестовых эксплуатаций с выявлением реальных, а не вымышленных требований…

Все это так. Но мы попробуем копнуть глубже.

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

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

Почему ERP сложнее внедрить чем учетную систему? Две проблемы

ERP – это не просто учетная система. Это система управления.

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

Отсюда уже видно, насколько сложнее, по сравнению с учетной системой:

Нейроны

А) обеспечить функциональность ERP, соответствующую всем тонкостям работы предприятия — чтобы она облегчала работу сотрудников, повышала качество и скорость процессов, а не стала обузой, усложняющей работу;

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

Проблема № 1. Сложность определения оптимального функционала

Почему так сложно определить именно тот ERP-функционал, который будет оптимален для данного предприятия?

Все знают аксиому: «Практика — критерий истины». Что это значит в случае внедрения ERP-системы?

Это значит что никакие теоретические изыскания и моделирование, разговоры с пользователями, анализ их пожеланий, и постановки задач и так далее, не позволят написать ТЗ для настройки ERP-системы «под ключ». Нельзя подходить к ТЗ на ERP как к архитектурному проекту строительства, по которому можно качественно построить дом в соответствии со всеми требованиями.

Причина проста: архитектурный проект описывает целевой материальный объект, а ТЗ ERP описывает деятельность людей, во взаимосвязи различных событий и ситуаций.

Деятельность людей намного более многогранная и содержит множество нюансов.

 Люди как винтики

— Материальный объект проще описать, представить заказчику во всех разрезах и свойствах, поскольку он статичен, а требования конечны. Дом не меняется с течением времени и имеет три измерения.

— Деятельность людей динамична, процесс разворачивается в четвертом измерении — времени…

Математики в таком случае говорят, что задача имеет «большую размерность».

Какие следствия из этого утверждения?

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

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

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

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

Картинка деревья

Видим, что проблема налицо, но мы постарались показать выше глубинные и объективные причины такого развития событий. Комикс не о бестолковости заказчика и разработчика, как можно подумать… Ничего таинственного! Просто ни заказчик, ни разработчик ни разу в жизни не видели качели. И вот к чему пришли в результате: качели в итоге получились, но не вполне удобные! Очевидно, что если бы сразу стали вешать веревки, прилаживать доски и пробовать конструкцию в деле, то результат получился бы куда лучше.

Со временем к вендорам и интеграторам начало приходить абсолютное понимание, как наиболее быстро и с наименьшими затратами создать и запустить ERP-систему. Этот подход, как было сказано выше, есть ни что иное, как «Доводка системы в процессе ее эксплуатации».

Вот веселый видеролик «Если бы программисты строили самолеты»:

Наглядно, не правда ли?

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

Уже многие компании заявляют свое конкурентное преимущество:

«Пока наши конкуренты 3 месяца пишут ТЗ, мы за это время уже начинаем работать в типовом решении и выдаем первые результаты, дорабатываем на практике. А в ТЗ все предусмотреть нельзя».

Наши рекомендации

Итак, вопрос ставится так — что лучше:

А) обследовать процессы, моделировать, разрабатывать ТЗ?

Б) или сразу «бросаться в бой» пользуясь типовым функционалом?

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

Девушка за компом

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

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

Это наш классический подход к выполнению больших проектов.

О проектной технологии компании ИТРП (полный проектный) цикл можно прочитать здесь>>>

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

Проблема № 2. Имплантация системы в переменчивую среду

Теперь рассмотрим вопрос — почему так сложно встроить ERP в процессы компании, в отличие, например, от блока регламентированного учета?

Начнем с того, что система учета и система управления – это разные системы.

ПрошлоеБудущее

• Система учета – фиксирует прошедшие события.

• Система управления – фиксирует не только прошедшие, но и будущие события.

Прошлое – фиксировано, будущее переменчиво!

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

Соответственно, если изменяется «начальное» событие — то нужно внести изменения во все зависимые события.

Элементарный пример: Принят заказ клиента, соответственно, сформирован заказ производству, под требуемые материалы сформирован заказ поставщику и согласован с поставщиком, выставлен счет клиенту, введена заявка на оплату поставщику, которая запущена по цепочке согласования… А теперь представим, что заказ клиента скорректирован. Система должна уметь в соответствии с изменением заказа — перестроить всю эту цепочку. Автоматически или вручную – это отдельный вопрос. Главное – результат.

ПадающееДомино

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

Тронем одно звено — развалится вся цепочка!

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

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

Именно в этом состоит тайная причина сложности внедрение систем управления, по сравнению с системами учета!

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

Проблема № 3. Пользователи – зло?

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

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

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

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

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

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

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

Новая система, таким образом,  выключается из бизнес-процесса и существует в «параллельной реальности».

Как с этим бороться? Один из методов — требовать предоставление всех отчетов, только полученных в новой системе.

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

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

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

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

Ответим на эти вопросы.

ТЕХНОЛОГИЯ ВНЕДРЕНИЯ ERP-СИСТЕМ
Лисин Николай, ИТРП

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

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

ОперацииНаОгороде

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

Технологии создания ERP-систем в настоящее время развиваются. Если еще лет 10 назад мы ориентировались на серию 34-х ГОСТов, то сейчас мало кто про них вспоминает. Возможно, лет через 10 мало кто вспомнит и про технологии, которые применяются сейчас.

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

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

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

При этом изначально известны, как правило, только несколько основных целей и некоторый небольшой объем исходных данных.

А сейчас  покажем, какие логические шаги (этапы) лучше всего выполнить при создании ERP-системы. Наши цели:

Шаги Пальцами

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

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

 

С чего можно начать?
Отметим, что очень редко система автоматизации создается сразу на все бизнес-процессы, и запускается сразу тоже по всем процессам.

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

Например, сначала запустить оперативный учет, а потом – диспетчеризацию производства.

Рассмотрим плюсы и минусы такого подхода.

Плюс

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

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

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

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

Плюсы в большинстве случаев на практике перевешивают минусы.

Семь раз отмерь — один раз отрежь?
Следующая рекомендация: попробуем усовершенствовать классическую «каскадную» модель работы.

В каскадной модели декларируется «системный подход»: сначала составлялась исчерпывающая проектная документация, продумывалась вся система в целом, затем выполнялись настройки – и только затем пользователей допускали «пощупать» систему в ходе опытной эксплуатации.

В каком направлении надо двигаться?

Обсуждения, совещания и поиск решения «на бумаге», как это было принято при каскадном подходе — можно считать теоретическими изысканиями. Сначала спроектировали – потом реализовали. В соответствии с пословицей «Семь раз отмерь – один раз отрежь». Хорошо ли это?

Что удивительно — этот очевидный подход для многих отраслей (например, для строительства), в ИТ-технологиях, оказывается, не самый оптимальный. Как это ни странно…

Представим себе, что заказчик нарисовал набросок дома, после чего привозятся стройматериалы и начинается немедленно строительство. Каменщики втыкают кирпичи, клиент сразу смотрит что получается, критикует, каменщик кладет кирпич на другое место… По ходу строительство клиент «созревает» где у него должно быть окно, а где — балкон… Бред?

Очевидно, что так строить дома нельзя. Может получиться вот что: :)

Уродливый Дом

История вопроса

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

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

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

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

Немного теории, представленной заказчикам

Экономическая оценка должна основываться на соотношении результатов и вовлечённых ресурсов. Обычно для этих целей оперируют показателем возврата инвестиций (Return on investments, ROI). Данный показатель представляет собой отношение чистой прибыли к сумме инвестиций за период владения активом. При этом под чистой прибылью понимают все поступившие в результате инвестиций доходы, в том числе, и разность между конечной стоимостью актива и суммой инвестиций.Согласно основам теории оценки проектов, для проведения полноценного инвестиционного анализа следует также рассматривать не общую величину затрат на проект (инвестиций) и итоговую величину «дополнительной» прибыли, а изменение их величины во времени — так называемую «приведённую стоимость». Однако, поскольку погрешности в статистике гораздо выше поправок на дисконтирование стоимости денег, эти коэффициенты в данном материале учитываться не будут.

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

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

снижение уровня запасов — в среднем на 17 %, лучший результат — 25 %;

повышение производительности — в среднем на 16 %, лучший результат — 28 %;

снижение себестоимости закупаемых материалов — в среднем на 7 %, лучший результат — 11 %;

улучшение обслуживания клиентов — в среднем на 16 %, лучший результат — 28 %,

и в итоге связанное с этим увеличение объёма продаж в среднем на 5 %, лучший результат — 8 %.

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

снижение общей величины дебиторской задолженности — в среднем на 8 %, лучший результат — 13 %;

в том числе снижение величины «необоснованной» дебиторской задолженности — в среднем на 63 %, лучший результат — 78 %;

увеличение кредиторской задолженности за счёт «разрешённой» — в среднем на 5 %, лучший результат — 9 %.

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

за максимальное значение ожидаемого эффекта примем среднее значение из статистических данных;

за минимальное значение — разность между средней величиной и её отклонением от максимальной величины.

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

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

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

Реальная история

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

Оценить затраты легко

Выполнить прогноз общих затрат по проекту было достаточно легко. Они включают в себя оплату работы экспертов и программистов ИТРП, которые не должны были превысить 4 млн руб., а также затраты совокупной стоимости внедрения и владения автоматизированной системой, т. е. стоимость программного обеспечения, обновления системы, оборудования, других технических средств. В общей сложности «с запасом» стоимость конкретного проекта получалась около 5 млн руб.*

Но как оценить доходы?

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

Пример расчёта экономического эффекта от внедрения системы автоматизации по выборочным статьям (на основании открытой статистики реализованных проектов)

Внешние цели автоматизации

Как рассчитать срок окупаемости проекта автоматизации? На этот вопрос обычно дают расплывчатые ответы. Попробуем разобраться…

От заказчиков можно услышать разные мнения о цели автоматизации, создания ERP-системы:

Мы хотим облегчить работу пользователей.

Мы хотим использовать возможности купленной программы в полном объеме (ведь не зря же купили?).

Мы хотим повысить прозрачность предприятия.

Мы хотим увеличить срок обслуживания клиентов.

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

Мы хотим отказаться от старой системы, потому что ее некому сопровождать.

Старая система работает слишком медленно.

В нашем случае основным назначением ERP системы является автоматизация производства/логистики/торговли/и т.д.

Старую систему невозможно развивать, в ней столько доработок что она «трещит по швам».

Мы хотим более современную систему.

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

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

Мы хотим уволить половину бухгалтеров.

Мы хотим, чтобы отгрузочные документы печатали, а не писали от руки.

Внедрения новой системы требует управляющая компания (собственник).

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

Определить, принесет ли поставленная цель выгоду предприятию, можно с помощью простого правила:

Цели автоматизации  должны быть внешними по отношению к процессу автоматизации!

Иными словами цели должны быть не внутри системы, а снаружи. Что же такое цель, внешняя по отношению к системе автоматизации?

Например, такие цели, как:

разработать некий набор печатных форм,

автоматизировать процесс сдачи приемки товара на склад,

автоматизировать процесс сбора затрат в производстве

— это цели внутренние.

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

Да, основным назначением ERP систем является автоматизация, но если это автоматизация ради автоматизации, то скорее всего, вы идете в никуда…

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

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

Причем эта цель измерима!

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

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

Грамотно сформулированные цели помогают расставить приоритеты и спланировать проектные работы.

К сожалению, далеко не на каждом проекте удается их вот так четко, однозначно, критериально описать. Но все-таки в большинстве случаев инициатор проекта понимает, зачем он все это затеял! На практике проекты, в которых поставлены явные, измеримые цели, составляют 70-80 процентов. Формулировка цели является главным показателем для оценки достигнутого результата после окончания проекта. Если цели не сформулированы, то по окончании проекта Заказчик может задать вопрос: «А что, собственно говоря, улучшилось и зачем потрачены деньги?».

Понятно, что в начале большинство Заказчиков хотят автоматизировать все! Зачем это нужно – не всегда понятно..

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

Автоматизация без сформулированных внешних целей – это «автоматизация ради автоматизации», выбрасывание денег на ветер. Вместо инструмента управления бизнесом автоматизация становится дорогой игрушкой.

Не все ли равно – руками перекладывать папочки на столе или двигать их мышкой на экране?

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

Но потом появился Вася Пупкин и сделал автоматизацию «по дружбе» за два дня бесплатно. Каким образом? Он просто ввел карточную систему «Канбан». Оказалось, что внешнюю цель – организацию оперативного снабжения торговых точек — можно достичь без всяких компьютеров, одним только перекладыванием бумажных карточек!

Критерий SMART

Помимо требования «внешности» цели, есть такой популярный критерий корректности цели – SMART. Это аббревиатура от английских слов:

Specific – «Конкретный»

Что конкретно вы хотите получить в результате? –Как оно выглядит, звучит, воспринимается?

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

Measurable – «Измеримый»

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

Attainable – «Достижимый»

Необходимо учитывать возможности проектной команды (да и вообще возможности предприятия).

Relevant – «Значимый»

Цель должна быть актуальной.

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

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

Time—bounded – «Соотносимый с конкретным сроком»

Цели без сроков исполнения – всего лишь мечты.

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

Как определить эффект от автоматизации?

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

Основной эффект от автоматизации – это качество управления. Как оценить эффект от принятия на работу нового толкового менеджера?

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

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

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

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

Возможно, это «черный проект», не нацеленный на результат. Ведь писать гораздо проще чем делать!

Так что такое «Черный проект автоматизации»?

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

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

Черный проект

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

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

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