Неудовлетворенность качеством системы как со стороны пользователей, так и со стороны руководства компании, потребность вручную заводить документы или сложности при получении необходимых данных – всё это может говорить о том, что в вашей компании используется сильно кастомизированная система. Такие системы требуют особого подхода к владению и сопровождению и привлечения высококвалифицированных специалистов.
В статье разберем:
-
Как отличить "сильно кастомизированную систему" от просто системы с большим количеством доработок;
-
Как могут сопровождаться сильно кастомизированные системы;
-
Как принять решение о том, что делать с такой системой;
-
Кто должен входить в команду поддержки сильно кастомизированной системы;
-
Разберем три кейса из нашей практики сопровождения кастомизированных систем на базе 1С:ERP.
Варианты сопровождения системы 1С:ERP с привлечением подрядчика
При сопровождении системы можно привлекать подрядчика к разным задачам с разной глубиной погружения. Выделяются три основных способа взаимодействия:
- Подрядчик решает отдельные задачи в рамках сопровождения.
Такой вариант подходит компаниям, у которых есть своя служба поддержки, и она справляется с основной массой рутинных задач. В этом случае подрядчик привлекается к отдельным сложным или нестандартным задачам, например, обновлению системы или развитию каких-то подсистем.
- Подрядчик является второй/третьей линией поддержки.
В этом случае в компании есть первая линия поддержки, которая решает рутинные задачи и закрывает пул наиболее частых обращений.
Подрядчик, в свою очередь, работает только с задачами, которые выходят за рамки "рутины" и требуют квалификации. При таком сценарии все задачи по развитию и улучшению системы ложатся на подрядчика.
- Подрядчик является всеми линиями поддержки.
Иначе говоря, все обращения по системе приходят к подрядчику. Наиболее дорогой, но и самый эффективный вариант. Ключевые специалисты подрядчика видят все возникающие проблемы, работают с закономерностями этих проблем, постоянно улучшают систему и исправляют ошибки.
Как понять, что нужна системная поддержка командой специалистов
Рассмотрим индикаторы, которые помогут определить, является ли ваша система "сильно кастомизированной" и, как следствие, требует системного подхода к поддержке.
В таблице ниже мы приводим сравнение характеристик систем, влияющих на требования к уровню поддержки:
Множество пересекающихся доработок – это ситуация, при которой система дорабатывалась итеративно, возможно, силами не одной команды и под требования разных пользователей.
Доработки в такой системе пересекаются между собой и/или с типовыми функционалом, часто подменяют собой типовой функционал. Тогда, при ошибке в одной доработке, "ломаются" несколько соседних, из-за чего нормальный бизнес-процесс становится невозможен.
Отсутствие структурированной документации заметно усложняет поддержку системы: чтобы понять, какие доработки были сделаны и для чего, специалист вынужден выяснять информацию у пользователей или разбираться самостоятельно.
Если ошибки системы носят точечный характер и не оказывают влияния на бизнес (не создают убытков или недополученной прибыли), то постоянная поддержка не является критически необходимой.
Если же при ошибке в системе бизнес терпит значительные убытки – это яркий индикатор того, что необходима системная поддержка программного продукта.
Что делать с сильно кастомизированной системой
Существует три различных пути развития сильно кастомизированных систем.
Путь №1. Не менять в подходе ничего. Новые ошибки – новые доработки. В таком случае риск того, что в какой-то момент система не сможет функционировать, никуда не исчезает – просто откладывается "на будущее".
Путь №2. Нормализация базы. Помимо работ по поддержке системы включает в себя:
-
Формирование и актуализацию документации;
-
Актуализацию инструкций;
-
(До)обучение сотрудников;
-
Рефакторинг кода;
-
Нормализация и поддержание матрицы прав доступа;
-
Реинжиниринг системы – аудит доработок, при котором ненужные исключаются или заменяются типовым функционалом.
-
Выполнение новых необходимых доработок с учетом встраивания их в целостную систему.
Путь №3. Перевнедрение. После проведения первичного аудита и определения текущего состояния базы можно оценить, сколько будет стоит нормализация системы и внедрение системы с нуля.
Если стоимость перевнедрения сопоставима со стоимостью нормализации за 1-1,5 года (с учетом стоимости минимального поддержания работоспособности системы на этот же период), то мы рекомендуем рассматривать перевнедрение.
Особенности сопровождения кастомизированной системы
Для сопровождения сильно кастомизированных систем нужна отдельная команда. Её можно сформировать как внутри компании, так и с привлечением подрядчика.
Ключевые аспекты такого сопровождения – компетенции команды и бюджет.
При сопровождении сильно кастомизированных систем предъявляются довольно высокие требования к квалификации специалистов. Речь идет не только о знании системы, но и об умении анализировать недокументированный функционал, общаться с пользователями, структурировать хаотично поступающую информацию.
Если система охватывает небольшое число подсистем, а бюджет ограничен, выгоднее нанять пару специалистов в штат, закрывая 80-90% задач своими силами, а для оставшихся 10% привлекать сторонние команды.
Если же в системе используются все подсистемы, то даже при ограниченном бюджете обратиться в стороннюю компанию будет дешевле: вероятность найти квалифицированного универсала крайне низкая, да и стоимость такого специалиста может быть сопоставима с привлечением подрядчика.
При обращении к подрядчику вам не придется брать на себя управления внутренней коммуникацией команды поддержки, что, конечно, удобно. Главный риск в таком взаимодействии – формирование компетенций по системе за контуром предприятия, поэтому на первый план выходит качество и прозрачность документации, которую подрядчик формирует.
Организация сопровождения системы
Два ключевых момента любого сложного сопровождения:
При фиксации обращений на стороне заказчика возникает зависимость от доступности и удобства инструментов, используемых в качестве системы фиксации, а также риск потери истории изменений для исполнителя.
Вариант с фиксацией на стороне исполнителя создает дополнительную нагрузку на ЛПР (лицо, принимающее решения) заказчика и временной "лаг" при регистрации обращений.
Наиболее комфортным, исходя из нашего опыта, является следующий подход:
-
Первичная обработка обращений происходит на стороне заказчика;
-
Целевые обращения попадают к подрядчику;
-
В систему заказчика передается решение или уточняющие вопросы.
Так ни одна из сторон не вмешивается во внутренние процессы второй, а работа выстраивается по принципу "вопрос – ответ – подтверждение получения ответа".
С точки зрения владения системой более логичным будет вариант, при котором все изменения в систему вносит исполнитель. Однако такой подход имеет свои недостатки: исполнитель будет вынужден регулярно вмешиваться в бизнес-процессы и может нарушить их нормальное течение.
Если все изменения в систему вносятся заказчиком, то и вся ответственность за процесс внесения изменений находится на заказчике. В таком случае часто страдает оперативность.
Промежуточный вариант – исполнитель вносит в систему только те изменения, которые не требуют блокировки базы и удаления из нее пользователей. Другие работы выполняет заказчик – в соответствии с внутренним регламентом компании.
Стоит также отметить: если у подрядчика есть право на загрузку изменений в систему заказчика, то эта функция возлагается на одного специалиста.
У всех перечисленных подходов есть как плюсы, так и минусы. Выбор между ними должен определяться составом команд, используемыми инструментами и возможностями сторон.
Состав команд и зоны ответственности
Состав команды со стороны заказчика должен включать:
-
ЛПР – ключевое лицо для коммуникации. Все запросы на изменения в системе должны проходить через него.
-
Владелец системы – человек, отвечающий за систему со стороны заказчика. Может быть ЛПРом.
-
IT-служба – техническая служба заказчика. Осуществляет фильтрацию обращений на предмет целесообразности передачи в работу подрядчику.
-
Ключевые пользователи – владельцы отдельных подсистем и процессов в системе.
-
Пользователи.
Нормальный процесс обработки запросов представлен на схеме:
Такой подход поможет, в том числе, систематизировать поток обращений от пользователей. Позволит проще увязывать между собой взаимоисключающие требования, проверять корректность работы предложенных решений и собирать обратную связь.
При формировании запроса какие-то уровни могут пропускаться, но игнорировать все – нельзя, иначе растет риск возникновения задач, которые не были верифицированы к исполнению и отфильтрованы на стороне заказчика. Это приводит к прямому увеличению расходов и дальнейшему усложнению коммуникации между заказчиком и подрядчиком.
Состав команды со стороны подрядчика:
-
ЛПР – является точкой входа информации со стороны заказчика и "маршрутизатором" для входящих обращений.
-
Архитектор контролирует взаимосвязи задач и курирует принимаемые решения.
-
Бизнес-консультанты – основные аналитики проекта.
-
Технический руководитель контролирует принятые к реализации доработки на предмет соответствия стандартам разработки и корректности реализации.
-
Разработчики выполняют адаптацию системы на основании ТЗ.
Схема процесса взаимодействия:
Архитектор и технический руководитель могут не участвовать в схеме взаимодействия, но подключаются к процессу уже "внутри" задач – осуществляя своего рода авторский надзор и контроль качества.
Нужны ли на таком проекте РП, архитектор и технический руководитель
Может возникнуть вопрос: "Действительно ли необходимо такое большое количество людей для сопровождения системы? Разве пользователь не могут напрямую обращаться к разработчикам?"
При матричной коммуникации на проектах сопровождения возникают следующие проблемы:
-
Отсутствие прогнозируемости бюджета периода: задачи идут стихийно, управление затратами не осуществляется.
-
Возникновение взаимоисключающих задач: требования одного пользователя могут противоречить требованиям другого.
-
Выполнение избыточных работ: при отсутствии централизации знаний о системе одни и те же задачи могут решаться по нескольку раз.
-
Увеличение эффекта "лоскутного одеяла": при отсутствии архитектора и технического руководителя каждый специалист будет выполнять работы, руководствуясь в том числе своими внутренними принципами и привычками, которые – без внешнего фильтра – дадут разнородный результат.
-
Нет возможности обеспечить единый процесс: отсутствие архитектора и технического руководителя усложняет анализ выполненных работ и увеличивает время на формирование ответа.
При этом, безусловно, специалисты общаются с пользователями. Но после этого общения выработанные решения проходят верификацию – как у подрядчика, так и у заказчика.
РП осуществляет функцию "единого окна" для заказчика:
-
Контролирует входящие запросы;
-
Выполняет функцию ответственного лица для заказчика;
-
Управляет командой подрядчика.
Архитектор является главным звеном по сохранению целостности решений:
-
Выявляет родственные задачи;
-
Контролирует выполнение работ с точки зрения связности;
-
Осуществляет аудит существующих решений в системе.
Технический руководитель обеспечивает единство реализаций:
Кейсы из нашей практики сопровождения кастомизированных систем на базе 1С:ERP
Кейс №1. Успешный.
Клиент – предприятие легкой промышленности. Занимается производством продукции из целлюлозы. Численность персонала – более 450 человек.
На предприятии использовалось девять различных систем на базе 1С, две из них – 1С:ERP, которые были внедрены пять лет назад. Документации в полном виде не существовало с момента запуска. Также в процессе эксплуатации в системы было внесено большое количество доработок, на которые документация и вовсе отсутствовала.
Инструкции – или неактуальны, или их нет. Матрица прав доступа была настроена стихийно, а не в соответствии с бизнес-процессами. Часть доработок дублировала типовой функционал.
Мы успешно работаем с клиентом уже более 1,5 лет, среднее количество часов поддержки в месяц – 250.
За это время специалистами "СофтБаланс" были выполнены следующие работы:
-
Настроена матрица прав доступа – в соответствии с бизнес-процессами заказчика;
-
Адаптирован производственный блок;
-
Нормализован расчет себестоимости;
-
Сформированы инструкций, персонал обучен работе в системе.
На данный момент стоит вопрос о внедрении ERP с нуля с переадаптацией функционала, поскольку клиенту необходимо поддерживать актуальную версию системы.
Кейс №2. Неудачный.
Клиент – фармацевтическая компания. Занимается производством лекарств и БАДов.
На предприятии использовалась одна система 1С:ERP, закрывающая весь контур учета. На момент старта проекта система была внедрена более пяти лет назад. Документация после запуска системы была, но в процессе эксплуатации выполнялись стихийные доработки – уже без ведения документации.
Длительность нашего сопровождения – пять месяцев. За это время были выполнены:
-
Адаптация подсистемы "Бюджетирование";
-
Нормализация закрытия периода;
-
Обновление системы на следующий релиз.
После чего взаимодействие с клиентом было прекращено по ряду причин:
-
Нежелание заказчика выстраивать нормальный процесс коммуникации: вести документацию по системе и организовать централизованное управление сопровождением.
-
Наличие на проекте еще одного подрядчика на поддержке и, как следствие, постоянные пересечения по задачам.
-
Длительные согласования оплаты часов, что приводило к увеличению сроков сдачи работ с нашей стороны и неудовлетворенности сроками выполнения уже заказчиком.
Как результат – экономическая незаинтересованность в такой работе с нашей стороны.
Кейс №3. Успешный.
Клиент – предприятие тяжелой промышленности. Производит различные металлоконструкции. Численность персонала – более 200 человек.
Используют две системы, одна из которых – 1С:ERP, внедренная четыре года назад. Документации не осталось, частично адаптация не соответствуют потребностям предприятия. Главная проблема – некорректный производственный учет, из-за чего возникали проблемы при закрытии месяца.
Клиент не мог решить: чинить существующую систему или перевнедрять. После проведения аудита и подготовки сметы работ было решено осуществлять поддержку текущей версии 1С:ERP.
Выполнены работы по обновлению системы, отключена часть доработок, некоторые процессы переведены на типовой функционал, актуализирована документация. Среднее количество часов поддержки в месяц – 180.
Ключевые результаты сопровождения за год:
-
Обновление на актуальную версию ERP;
-
Нормализация учета и сдачи отчетности;
-
Отключение лишних доработок и возврат к типовому функционалу;
-
Начали подпроект по внедрению 1С:Документооборот и настройке бесшовной интеграции с 1С:ERP.
Заключение
Подведем итоги:
-
Чем старше система, тем большего объема работ по сопровождению она требует;
-
С течением жизненного цикла системы документация по ней нуждается в актуализации и адаптации;
-
Чем сильнее кастомизация системы, тем выше требования к команде обслуживания и затраты на управление таким обслуживанием;
-
Любая система рано или поздно требует перевнедрения – даже если в её основе лежит актуальный программный продукт.
С ростом трудозатрат на обслуживание, у вас появляется архитектор, технический руководитель и РП, которые контролируют целостность и корректность вносимых изменений, что, в свою очередь, ещё больше повышает стоимость владения системой.
К сожалению, какими бы качественными ни были внедрение и сопровождение, на определенном этапе количество расхождений функционала системы с реалиями бизнеса становится таким, что дешевле и продуктивнее внедрить систему с нуля, чем пытаться адаптировать существующую под необходимые изменения.
