Проектная технология 2: “Процессное моделирование”

Решения

предложенные решения

• Классический подход к проекту автоматизации предполагает написание некоего технического задания, которое содержит набор требований, которым должна соответствовать созданная в рамках проекта информационная система.
  
  У этого подхода есть два важных недостатка в случае проекта внедрения программы «1С:ERP»:
  
  • Описание детальных требований на комплексную систему автоматизации масштаба предприятия займет очень много времени и будет стоить очень дорого.
  
  • У нас уже есть готовая конфигурация «1С:ERP» и нам нет необходимости повторно описывать требования к её функционалу – она уже создана и существует.
  
  В случае проекта внедрения готовой системы, речь скорее идет о том, чтобы описать то, как пользователи конкретного предприятия будут работать в этой системе. А говоря формально, требуется определить, как готовый функционал программы ложится на особенности бизнес-процессов заказчика.
  
  Исходя из этой особенности, данный этап проекта автоматизации называется процессным моделированием.
  
  В самом начале работ требуется провести следующие подготовительные мероприятия:
  
  Во-первых, нужно составить устав проекта – этот документ содержит сутевую часть из технико-коммерческого предложения и договора (цели проекта, задачи, требования, сроки, ограничения, риски), а также развернутое описание процесса организации проектных работ:
  
  1. Раздел «Управление проектом» – содержит список лиц, ответственных за ход проекта:
  
  • Куратор проекта со стороны заказчика – лицо, отвечающее за стратегические вопросы ведения проекта. К стратегическим вопросам относятся верхнеуровневые цели и задачи проекта, сроки выполнения работ, объемы финансирования проекта. Также куратор проекта по запросу руководителя проекта может участвовать в урегулировании споров и конфликтов.
  
  • Руководитель проекта со стороны заказчика – лицо, отвечающее за ход проекта и его результаты в целом. Руководитель проекта заказчика организует работу сотрудников заказчика над проектными задачами, контролирует срок их выполнения, контролирует график проектных работ как со стороны заказчика, так и со стороны исполнителя, контролирует удовлетворенность сотрудников заказчика результатами проектных работ. При возникновении споров по стратегическим вопросам может обратиться к куратору проекта для их разрешения.
  
  • Руководитель проекта со стороны исполнителя – наш представитель, отвечающий за управление нашей проектной командой – также ставит задачи, контролирует сроки их выполнения, в целом способствует наискорейшему продвижению проекта к намеченной цели. Также контролирует расходы из бюджета проекта и границы проекта, может инициировать обращение к куратору проекта в спорных ситуациях.
  
  
  Наши рекомендации:
  
  Проект внедрения системы 1С:ERP – это комплексное мероприятие, затрагивающее работу практически всех служб предприятия. Как следствие, в процессе его выполнения могут возникать внутренние конфликты заказчика – например из-за необходимости пересмотра рабочих обязанностей одного отдела по требованиям другого.
  
  Предположим бухгалтерии необходима более детальная информация о том, как формируются затраты в производстве – это возможно потребует дополнительных усилий от сотрудников цехов или заставит их реорганизовать свою работу. Это серьезный конфликт, который способен парализовать проектные работы.
  
  Чтобы исключить такие проблемы мы рекомендуем назначать на роль куратора проекта одного из высших должностных лиц предприятия – например, управляющего или исполнительного директора. Идеальным будет в роли куратора владелец бизнеса. В любом случае это должен быть топ-менеджер заказчика, которому подчинены руководители других подразделений предприятия, участвующих в проекте.
  
  Если руководитель заказчика такого уровня по какой-то причине не может систематически участвовать в проектных работах он должен приказом по предприятию назначить на эту роль подходящего функционального руководителя и явно переподчинить ему остальных топ-менеджеров в рамках проектных работ.
  
  2. Раздел «Коммуникации на проекте» – содержит описание возможных методов коммуникаций.
  
  
  Наши рекомендации:
  
  Одна из наиболее частых проблем на проектах автоматизации – это отсутствие регулярного контроля за коммуникациями.
  
  Как следствие: согласование документов затягивается, важные решения своевременно не принимаются, поручения не выполняются, информация теряется. Мы предлагаем решить эту проблему с помощью инструментов автоматизации – программы «1С:Документооборот». Что позволяет эта система:
  
  1. Согласовывать проектные документы, вести учет замечаний к документам и контролировать их устранение.
  
  2. Готовить проектные мероприятия: оповещать сотрудников о предстоящем мероприятии, рассылать им необходимые документы для ознакомления, вести итоговые протоколы, контролировать исполнение поручений.
  
  3. Организовать базу знаний – архив проектных документов.
  Программа «1С:Документооборот» достаточно проста в освоении, поэтому мы настоятельно рекомендуем сразу вписать её в устав проекта, как основное средство для организации коммуникаций на проекте. Дополнительным плюсом является то, что, начав пользоваться этой системой в начале проекта, сотрудники заказчика смогут в дальнейшем использовать полученные навыки для решения внутренних задач – например для автоматизации собственного документооборота предприятия.
  
  Для нас, как для исполнителей проекта автоматизации, использование программы «1С:Документооборот» в качестве инструмента управления коммуникациями также является значительным подспорьем в работе, поэтому мы подготовили бесплатный базовый учебный курс по этой системе для всех желающих, а также при приобретении у нас лицензии на эту систему, мы бесплатно проводим его первичную настройку под задачи управления проектом, а также передаем заказчику наши готовые доработки (о которых будет рассказано далее).
  
  
  После утверждения устава проекта, готовится приказа о начале проектных работ. Цель приказа - оповестить сотрудников предприятия о целях и задачах этого мероприятия, формально назначить руководителей работ со стороны заказчика и определить структуру подчинения согласно устава проекта.
  
  Перед началом процессного моделирования также должны быть созданы следующие документы:
  
  • Реестр бизнес-процессов предприятия
  
  • Матрица ответственности
  
  Работу с этими документами лучше объяснить на примере: на начальном мы плохо понимаем особенности работы заказчика, но он в целом понимает, что у предприятия есть несколько глобальных бизнес-процессов, подлежащих автоматизации, например:
  
  1. Процесс продажи продукции
  
  2. Процесс производства продукции
  
  3. Процесс закупки необходимых для производства материалов и комплектующих
  
  4. Процесс хранения материальных запасов
  
  5. Процесс управления денежными средствами предприятия
  
  6. Процесс получения отчетности о результатах фин.-хоз. деятельности
  
  Это будут наши корневые бизнес-процессы, которые мы на начальном этапе занесем в реестр бизнес-процессов предприятия.
  
  Кроме самих бизнес-процессов нужны ответственные сотрудники-эксперты со стороны заказчика, которые расскажут нам как протекают эти процессы, а потом смогут оценить предложенное решение по автоматизации этих процессов.
  
  Для корневых бизнес-процессов такими ответственными сотрудниками будут руководители функциональных подразделений заказчика.
  
  Далее наши бизнес-аналитики совместно с представителями заказчика начнут декомпозицию корневых процессов до их составных подпроцессов. На примере процесса продажи это может выглядеть следующим образом:
  
  1. Процесс продажи продукции.
  1.1. Процесс обработки нового запроса от клиента.
  1.2. Процесс оформления заказа клиента.
  1.3. Процесс контроля расчетов с клиентами.
  1.4. Процесс обработки рекламаций клиентов.
  
  Получившиеся подпроцессы фиксируются в реестре бизнес-процессов. Для них определяются свои ответственные эксперты.
  Декомпозиция может идти дальше, например, процесс обработки нового запроса от клиента может быть детализирован до:
  
  1. Процесс продажи продукции.
  1.1. Процесс обработки нового запроса от клиента.
  1.1.1. Процесс подготовки коммерческого предложения.
  1.1.2. Процесс подготовки проекта договора.
  1.1.3. Процесс заключения нового договора
  
  Декомпозиция останавливается в тот момент, когда текущий эксперт может без привлечения других специалистов полностью описать все шаги процесса и что на них происходит:
  
  • Какие действия совершаются.
  • Какие документы и как оформляются.
  • Какие отчеты формируются.
  
  В итоге получается сводный реестр бизнес-процессов автоматизируемого предприятия и перечень экспертов (матрица ответственности), которые смогут адекватно оценить качество реализации этих бизнес-процессов во внедряемой системе автоматизации.
  
  Реестр бизнес-процессов, как и матрица ответственности не являются статичными документами и могут уточняться в процессе моделирования и последующих этапов проекта.
  
  На основании полученных документов (реестра и матрицы) готовится график опроса экспертов заказчика.
  
  В процессе опроса эксперт демонстрирует то, как работа ведется на данный момент, высказывает свои пожелания по модернизации сложившихся процессов. Наш бизнес-аналитик анализирует эту информацию и заполняет протокол опроса, в котором фиксируются ключевые моменты опроса.
  
  По итогам опроса, аналитик готовит контрольный пример в программе, который демонстрирует эксперту заказчика.
  Демонстрируется то, как работа будет выглядеть после перехода на новую программу. По итогам демонстрации заполняется протокол демонстрации, в котором фиксируются замечания эксперта.
  
  
  Демонстрация может вестись в несколько итераций, до тех пор, пока или эксперт не подтвердит, что его процесс верно отражен в контрольном примере, или не будет составлен перечень функциональных разрывов (несоответствий) – потребностей по доработке типовой конфигурации под особенности работы заказчика. Функциональные разрывы фиксирует бизнес-аналитик, к каждому функциональному разрыву дается краткое описание необходимой модификации программы и примерная трудоемкость такой модификации.
  
  
  Наши рекомендации:
  
  На этапе процессного моделирования мы не готовим полноценные технические задания на модификацию программы по функциональным разрывам. Причина следующая – до окончания комплексного моделирования мы не можем оценить значимость каждого функционального разрыва –кажущееся несоответствие в работе типовой программы может быть просто обычной рабочей привычкой сотрудника, о которой он забудет спустя неделю использования новой программы. Наша задача учесть все эти несоответствия, провести примерную оценку стоимости их устранения и вынести их на обсуждение с руководством заказчика.
  
  После того как такие несоответствия будут должным образом оценены и признаны значимыми для результатов проектных работ, мы уже на этапе адаптации типовой конфигурации готовим подробное техническое задание на доработку и согласуем его с тем экспертом, который заявил исходный функциональный разрыв.
  
  После того как демонстрация контрольного примера завершена и зафиксирован список обнаруженных функциональных разрывов (если они есть), бизнес-аналитик приступает к формальному описанию автоматизируемого процесса в документе «Процессная модель».
  
  Описание выглядит следующим образом:
  
  
  1. Дается описание входящего события, которое инициирует процесс.
  2. Перечисляются роли сотрудников, участвующих в процессе.
  3. Дается описание действий (шагов процесса), которые совершает тот или иной сотрудник.
  4. Для каждого шага указывается соответствующее действие в программе – какой объект конфигурации используется, что с ним делается, с какой целью.
  5. Дается описание исходящих событий, которые инициируют другие процессы.
  
  Цель этого описания – зафиксировать достигнутые договоренности с экспертом по процессу и создать референтную модель работы предприятия в программе «1С:ERP».
  
  
  Наши рекомендации:
  
  В нашей работе мы используем средства автоматизированного описания бизнес-процессов, которые позволяют быстро выявлять и устранить возможные противоречия в работе пользователей с одними и теми же объектами конфигурации «1С:ERP».
  
  Как это выглядит на практике – предположим два наших аналитика параллельно ведут опрос двух служб предприятия – отдела продаж и отдела снабжения. Обе службы используют в работе справочник номенклатуры, но в одном случае речь идет о продаваемых товарах, а в другом о закупаемых материалах. Эксперты служб могут высказать противоречивые требования к тому, как должна выглядеть карточка товара, какова должна быть последовательность действий при заведении нового товара и т.п. Если мы оперативно не устраним эти противоречия, это можем крайне негативно сказаться на последующих этапах работ – возможно будут проведены некорректные доработки, написаны неверные инструкции, люди будут плохо обучены и не смогут начать работать в новой системе. По факту потребуется повторное дорогостоящее перевнедрение части системы.
  
  Для того чтобы исключить подобные проблемы, мы полностью автоматизировали процесс подготовки процессной модели на базе функционала программы «1С:Документооборот». Для этого нами созданы новые объекты этой конфигурации:
  
  1. Реестр бизнес-процессов автоматизируемого предприятия
  2. Матрица ответственности
  3. Роли пользователей внедряемой системы
  4. Реестр объектов внедряемой системы
  5. Описание действий пользователей во внедряемой системе
  6. Реестр функциональных разрывов
  
  Также в системе «1С:Документооборот» ведутся все проектные протоколы.
  
  После проработки всех процессов заказчика и выявления всех функциональных разрывов наши бизнес-аналитик совместно с нашей группой разработки проводят оценку трудоемкости устранения функциональных разрывов. В эту оценку также включаются работы по написанию обработок по автоматизированному переносу исторических данных (справочников, текущих остатков и т.п.).
  
  Процессная модель и реестр функциональных разрывов передается на проверку и согласование заказчику. Если объем трудозатрат по доработке типовой конфигурации «1С:ERP» превысил запланированный бюджет проекта, инициируется совещание с куратором проекта, для определения возможных источников финансирования – часть задач может быть вынесена на следующие очереди работ, часть может быть отклонена, часть профинансирована за счет исключения других, второстепенных объемов работ.
  
  После согласования заказчиком процессной модели и реестра функциональных разрывов проект переходит на этап адаптации (доработки) типовой конфигурации «1С:ERP».
  
  
  Наши рекомендации:
  
  Процессная модель – это объемный документ на несколько сотен страниц, его согласование со стороны заказчика может значительно затянуться из-за необходимости полной вычитки итогового документа. Наши средства автоматизированного описания бизнес-процессов на базе конфигурации «1С:Документооборот» позволяют значительно ускорить эту работу – при завершении описания очередного процесса, эксперт заказчика сразу визирует корректность этого описания. Все изменения в процессе возможны только после временного снятия визы и повторного визирования экспертом. При таком подходе не требуется повторная вычитка итоговой модели – её качество уже подтверждено визами экспертов.