Проектная технология 5: “Опытно-промышленная эксплуатация системы”

Решения

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

• Этап опытно-промышленной эксплуатации начинается с того, что в новую программу вносятся начальные данные. Этот процесс может происходить как в автоматическом режиме (с использованием обработок, которые были созданы на этапе адаптации системы), так и в ручном режиме, когда пользователи заказчика под контролем наших консультантов заполняют необходимые справочники системы.
  
  Работа ведется согласно утвержденного графика, в котором прописаны раздел учета, срок переноса данных, консультант и ответственные за проверку данных (чаще всего это тот же эксперт заказчика, который участвовал в подготовке процессной модели предприятия).
  
  По окончании работ по переносу информации по тому или иному разделу учета оформляется протокол проверки начальных данных, в котором ответственный представитель заказчика фиксирует свои претензии к качеству произведенных работ, а наш консультант определяет сроки устранения выявленных проблем. Если ошибок не выявлено, считается, что работы по переносу завершены.
  
  
  Наши рекомендации:
  
  Чаще всего внедряемая система «1С:ERP» заменяет несколько исторических систем заказчика – это могут быть отдельные самописные программы для ведения складского учета, учета производства, отдельные системы бухгалтерского учета, обмен между которыми происходит в полуручном режиме. В такой ситуации одни и те же справочники могут содержать разную информацию в разных учетных системах. Например, дробиться и дублироваться справочник номенклатуры по складам/цехам, дублироваться сведения о контрагентах (поставщиках) в складской и бухгалтерской программе.
  
  Перед предприятием встает задача по унификации справочников и исключении дубликатов информации при переходе на новую программу.
  
  Мы предлагаем два варианта решения этой проблемы:
  
  • Самым правильным подходом будет определение для каждого справочников уникальных наборов свойств, различные значения которых гарантируют уникальность каждой записи справочника. Например, для поставщиков и покупателей такими уникальными свойствами будет значения ИНН и КПП. Тогда при загрузке контрагента из исторической системы исключается его дублирование в новой программе. К сожалению, для большинства справочников таких готовых свойств нет – их нужно определить на этапе доработки системы, когда готовятся обработки по загрузке начальных данных. Выработка правил уникальной идентификации справочников и согласование их со всеми заинтересованными лицами заказчика может занять достаточно много времени и затянуть подготовительные работы.
  
  • Второй вариант решения более быстрый, но ресурсоемкий для заказчика – он заключается в создании временных промежуточных справочников в новой системе, куда производится загрузка всей информации из исторических систем «как есть» – со всеми возможными дубликатами. Далее пользователям, ответственным за перенос информации, выдается набор обработок, которые позволяют вручную пометить дубликаты. После окончания этой работы унифицированные данные загружаются в рабочие справочники системы.
  
  При необходимости оба решения могут комбинироваться – например справочник контрагентов переносится с автоматической сверткой по ИНН и КПП, а для справочника номенклатуры создается буфер переноса, где пользователи вручную исключают дубликаты информации, поступившей из различных исторических систем учета.
  
  Для ускорения ручного поиска дубликатов нами был разработан инструментарий, который группирует элементы справочников по ключевым словам в наименовании. Далее пользователю остается только проверить, подтвердить или скорректировать полученную группировку дубликатов.
  
  По окончании работ по вводу/загрузке начальных данных, пользователи приступают к использованию новой системы. Чаще всего, работа одновременно ведется в двух системах – в исторической системе и в программе «1С:ERP». Делается это для того, чтобы подстраховаться от возможных сбоев в работе новой системы, а также для того, чтобы сверить результаты, и исключить возможные ошибки в учете.
  
  
  Наши рекомендации:
  
  Работа в двух системах учета одновременно приводит к повышенной нагрузке на сотрудников заказчика – ведь кроме учетных задач у них есть их непосредственные рабочие обязанности – приемка и отгрузка товара, производство продукции и т.п.
  
  Мы рекомендуем перед началом этапа опытно-промышленной эксплуатации обязательно разработать средства дополнительной положительной мотивации пользователей – например, учредить премиальный фонд на время повышенной нагрузки.
  Еще один вариант снижения нагрузки на персонал заказчика – это привлечение дополнительных сотрудников на временные трудовые договоры на период перехода. Это могут быть низкоквалифицированные специалисты (например, студенты) которые будут отвечать только за резервный ввод информации в историческую систему, тогда как штатные сотрудники предприятия будут осваивать новую программу.
  
  Кроме организационных мероприятий, по согласованию с заказчиком, могут быть разработаны технические решения, исключающие двойной ввод информации. Например, автоматический перенос новых документов из новой программы обратно в исторические системы. Затем производится ручная сверка итоговых отчетов и поиск возможных ошибок в работе новой программы. В случае возникновения сбоя, пользователи могут оперативно вернуться в старую программу и продолжить работу там. Минусом такого подхода является его высокая стоимость для заказчика – ведь нам приходится разбираться в устройстве исторических систем и писать обработки обмена документами. Мы рекомендуем такой подход только для высоконагруженных участков работы – там, где даже незначительный простой может обернуться значительными убытками для предприятия.
  
  Несмотря на все организационные и технические мероприятия по снижению трудоемкости двойного учета, всегда есть риск того, что пользователи не будут успевать выполнять свои обязанности по работе в новой системе. Чаще всего это происходит на больших предприятия, где количество пользователей измеряется сотнями и нельзя установить ручной контроль за их действиями. В таком случае мы предлагаем заказчику механизм автоматизированных контрольных проверок – это небольшие запросы к базе данных «1С:ERP», из которых можно:
  
  1. Собрать статистику по использованию новой системы – сколько документов было введено, как оперативно эти документы вводились, какие есть отклонения от исторической системы.
  
  2. Проконтролировать правильность ввода данных – не забыл ли пользователь выполнить те или иные действия в программе.
  
  С помощью этой информации можно оперативно выявить проблемные участки и разработать необходимые организационные или технические решения для устранения найденных проблем.
  
  Наш механизм контрольных проверок является универсальным настраиваемым инструментом, который может использоваться для контроля любых действий пользователей – единственным минусом для заказчика является стоимость его настройки. Для того чтобы частично компенсировать этот минус, мы создали базу стандартных контрольных проверок, которая бесплатно передается нашим клиентам в готовом виде.
  
  Наши работы на этапе опытно-промышленной эксплуатации можно условно поделить на два основных направления:
  
  1. Консультации пользователей по использованию новой программы – некий вариант повторного экспресс-обучения уже в процессе работы.
  
  2. Доработка внедряемой системы на основании выявленных функциональных разрывов и технических ошибок в момент опытно-промышленной эксплуатации.
  
  Консультации ведутся оперативно на основании обращений пользователей, все поступившие обращения в обязательном порядке фиксируются в реестре запросов. Назначение данного реестра – выявить наиболее проблемных пользователей, которые чаще всего обращаются с одинаковыми вопросами, а также выявить слишком сложные технические решения, которые являются основанием для множества обращений от разных пользователей.
  
  С проблемными пользователями требуется провести организационную проработку – выявить причины, почему они постоянно забывают, как выполнять те или иные действия в программе. Возможно подготовить дополнительные инструкции по использованию системы, возможно как-то мотивировать пользователя к ответственной работе.
  
  По проблемным техническим решениями нужно провести повторное моделирование работы пользователей совместно с экспертом заказчика и возможно доработать (упростить) систему для устранения причины массовых обращений.
  
  
  
  Наши рекомендации:
  
  Наилучшим подходом к организации процесса консультирования является использование технических средств регистрации новых заявок от пользователей. Это может быть какая-то собственная система сервисдеска заказчика, если такой нет, мы можем предложить использовать нашу адаптированную программу «1С:Документооборот». Её преимущества:
  
  1. Простота создания нового обращения – пользователь может сделать это не выходя из программы «1С:ERP», просто создав заявку в техническую поддержку на основании проблемного документа. Или отправив запрос на поддержку по электронной почте. Или открыв простую форму web-интерфейса программы.
  
  2. Автоматическая классификация обращений по типам – от какого отдела, по какой функциональности программы (при вводе заявки на основании документов «1С:ERP»).
  
  3. Простота настройки и перестройки маршрутов автоматической обработки заявок в зависимости от их типа.
  
  4. Автоматическое формирование базы знаний по типам обращений от пользователей – решение, предложенное одним консультантом, сразу доступно другим консультантам при появлении новой заявки по схожей тематике. Это значительно ускоряет процесс обработки заявок и позволяет избежать противоречий в рекомендациях от разных консультантов.
  
  5. Готовые статистические отчеты по заявкам – их количество, тематика, проблемные пользователи, проблемная функциональность, скорость закрытия заявки, варианты предложенных решений.
  
  6. Готовая интеграция с базой инструкций, созданных на этапе обучения – пользователь может сам открыть необходимую ему инструкцию прямо из конфигурации «1С:ERP».
  
  В любом случае, вне зависимости от того какой инструмент будет выбран для сбора обращений от пользователей, обязательным является регистрация всех заявок и регулярный анализ полученной статистики. Совершенно недопустима работа «по телефону», когда консультант работает с пользователем минуя реестр обращений – в таком случае техподдержка обречена на постоянные повторы вопросов, а у пользователей нет реальных стимулов для запоминания полученной информации – всегда можно просто так позвонить еще раз и повторно задать свой вопрос.
  
  
  
  Второе направление работ этапа опытно-промышленной эксплуатации – это исправление выявленных технических ошибок, а также оперативная доработка внедряемой системы, по выявленным функциональным разрывам (которые не были заявлены заказчиком на этапе процессного моделирования).
  
  Та часть обращений пользователей, которая связана с явными техническими ошибками, сразу передается в работу нашим программистам на исправление.
  
  Для обнаруженных функциональных разрывов процедура несколько иная: во-первых, наш бизнес-аналитик определяет объем необходимых трудозатрат на доработку системы, во-вторых, эксперт заказчика совместно с руководителем проекта заказчика устанавливает приоритет задачи, далее определяет источник финансирования доработки – необходимые дополнительные затраты могут превышать объем средств, выделенных на этап опытно-промышленной эксплуатации и требуется дополнительное финансирование, за которым нужно обратиться к куратору проекта.
  
  После того как все вопросы согласованы, бизнес-аналитик готовит техническое задание на доработку, которое, после согласования с экспертом, отдается в разработку – также как это было на этапе адаптации системы.
  
  
  Наши рекомендации:
  
  Наша проектная практика показывает, что даже при условии качественного выполнения этапа процессного моделирования и этапа доработки системы, на этап опытно-промышленной эксплуатации приходится порядка 30-40% доработок системы.
  Причины здесь в том, что за относительно короткий срок моделирования эксперты заказчика не успевает комплексно разобраться в особенностях новой системы, а наши бизнес-аналитики не успевают достаточно глубоко погрузиться в специфику работы заказчика. Как следствие – регулярная «доводка» системы в момент начала работы с ней.
  
  Здесь не поможет ни увеличение срока проектирования, ни увеличение числа привлекаемых экспертов/бизнес-аналитиков. Это не форс-мажор, а штатная рабочая ситуация – так проходят все проекты.
  
  Чтобы такие «неожиданные» доработки не помешали успешному завершению проектных работ, мы придерживаемся следующего подхода:
  
  1. В бюджет проекта на этап опытно-промышленной эксплуатации сразу закладываются деньги под работу нескольких программистов – резервная сумма зависит от масштаба заказчика. Это поможет избежать проблем с финансированием. Если же этот бюджет останется невостребованным – он может быть перенаправлен на цели дальнейшего развития системы.
  
  2. Мы полноценно документируем наши срочные доработки с пересмотром процессной модели даже на этапе опытно-промышленной эксплуатации – так чтобы они не вошли в противоречие друг с другом.
  
  По мере того, как пользователи осваивают новую систему, уменьшается количество новых обращений, система стабилизируется и передается на сопровождение ИТ службе заказчика. Документальным свидетельством данного факта (стабилизации системы) является все тот же реестр обращений пользователей, где не остается незакрытых заявок, связанных с ошибками системы, а все потребности по доработке системы или выполнены, или отнесены заказчиком на следующую очередь автоматизации.
  
  Оформляется акт о приемки системы в промышленную эксплуатацию – проект завершается.
  
  
  Наши рекомендации:
  
  Лучшим результатом окончания проектных работ является результат, при котором заказчик может самостоятельно сопровождать систему без привлечения сторонних ресурсов. Чтобы добиться этого, мы всегда предлагаем заказчику поэтапную передачу технической поддержки – в самом начале работ все обращения от пользователей сразу попадают нашим консультантам, и мы их самостоятельно обрабатываем. Далее мы предлагаем вводить в работу консультантов заказчика – чтобы они в режиме ознакомления разбирались с проблемами пользователей и их решением. Далее консультанты заказчика становятся первой линией поддержки – они принимают обращения от пользователей и стараются с ними разобраться самостоятельно, наши консультанты привлекаются только для решения сложных вопросов, а также в случае технических ошибок или возникновения потребностей в доработке системы.
  
  При таком подходе, к тому моменту, когда устранены все технические ошибки и система прошла окончательную доводку, консультанты заказчика способны полностью заменить наших консультантов без всякого ущерба для процесса текущей поддержки пользователей.