До замены учётной системы: что меняется вместе с платформой
Учётная система хранит не только данные. В ней закреплён порядок работы компании — и вместе с системой заменяется он.
Решение о замене учётной системы принимается по понятным основаниям. Прежняя не поддерживает выросшие объёмы, поставщик прекратил развитие продукта, требуется переход на отечественное решение, накопленные доработки сделали обновление невозможным. Основания технические, и проект получает соответствующую форму: выбор платформы, конкурс подрядчиков, техническое задание, срок запуска.
Форма определяет и способ подготовки. Компания описывает требования к системе — какие справочники, какие отчёты, какие интеграции. Описание того, как устроена сама работа, при этом обычно не составляется: считается, что процессы известны и переносятся вместе с данными.
Что закреплено в учётной системе помимо учёта
Система планирования ресурсов предприятия — ERP, если пользоваться принятым сокращением, — хранит не только записи об операциях. В её настройках закреплено устройство работы: последовательность согласований, права доступа, признак завершённости документа, правила формирования цены, порядок закрытия периода.
Каждое из этих правил когда-то было управленческим решением. Со временем оно перестало восприниматься как решение и стало восприниматься как свойство программы: сотрудник объясняет порядок словами «система так требует». Замена системы возвращает все эти правила в состояние выбора одновременно.
Порядок согласования: сколько подписей требует документ и в какой последовательности. Границы полномочий: кто вправе изменить цену, провести списание, закрыть период. Момент признания: когда операция считается совершённой и попадает в отчётность. Признак завершённости: при каких заполненных полях документ считается готовым. Правила блокировки: что система запрещает и по какому основанию. Ни одно из перечисленного не является технической настройкой по существу; всё перечисленное настраивается технически.
Две стратегии переноса и свойства каждой
Перенос сложившегося порядка. Новая система настраивается так, чтобы работа шла привычным образом. Подход бережёт людей и сокращает сопротивление. Свойство подхода: вместе с работающим порядком переносится и накопленный дрейф — обходные пути, исключения, ставшие правилом, шаги, выполняемые помимо системы. Компания получает современную платформу с зафиксированным на ней устройством работы десятилетней давности, а стоимость доработок под привычные особенности нередко превышает стоимость самой платформы.
Переход на типовую модель системы. Работа перестраивается под то, как устроен выбранный продукт. Подход даёт чистую конфигурацию, дешёвое обновление и сокращение доработок. Свойство подхода: типовая модель не знает про те особенности работы компании, которые составляют её преимущество. Перестройка задевает их наравне с накопленным дрейфом, поскольку различить одно от другого без описания невозможно.
Выбор между двумя стратегиями и есть главное решение проекта. Принимается оно, как правило, по ходу внедрения, на уровне отдельных участков, и результат складывается из десятков частных решений, принятых людьми, у которых не было полной картины.
Различить накопленный дрейф и преимущество компании можно только по описанию работы. Без описания перестройка задевает и то и другое.
Момент запуска
Второе решение касается темпа. Одновременный перевод всех участков сокращает срок переходного периода и избавляет от временных связок между старой и новой системами. Он же собирает все риски в одну дату.
Известен случай: компания пищевой отрасли запустила три системы разом — учётную, планирующую и работающую с клиентами — на сокращённом графике, приурочив запуск к периоду перед пиковым сезоном. В годовом отчёте компании причина последовавшего провала отгрузок названа прямо: затруднения в исполнении заказов, обслуживании клиентов и складских операциях, возникшие после запуска новой информационной системы и новых процессов. Невыполненными остались заказы на сумму порядка ста миллионов долларов. Технологии при этом работали.
Существенно, что в формулировке отчёта рядом стоят две вещи: новая система и новые процессы. Компания меняла их одновременно, и разделить последствия оказалось невозможно.
Средний перерасход составил 27%. При этом каждый шестой проект из выборки оказался «чёрным лебедем» — с перерасходом в среднем 200% и превышением срока почти на 70%.
Почему технологическая часть редко бывает причиной
Разбор неудачных внедрений устойчиво выводит к организационным основаниям: сжатый график, отсутствие сверки вручную на переходный период, недостаточное описание того, как работа шла до замены, перенос ответственности за содержание решений на подрядчика.
Подрядчик при этом действует добросовестно. Он настраивает систему в соответствии с полученным описанием и не располагает средствами проверить, соответствует ли описание практике. Вопрос «а как это происходит в действительности» находится за границей его подряда и за пределами его доступа к компании.
Отсюда и распределение ролей, при котором проект даёт результат. Настройка, разработка, перенос данных, обучение — за подрядчиком. Описание работы, выбор между сохранением и перестройкой на каждом участке, признак результата и ответственность за него — за компанией. Смещение второй части на подрядчика превращает управленческие решения в технические по форме и оставляет их непринятыми по существу.
Российская реальность
Замена учётных систем в российских компаниях идёт сейчас волной. Проект при этом нередко воспринимается как вынужденная техническая замена — поставить то же самое на другой платформе, — и вопрос об устройстве работы не ставится вовсе, поскольку менять работу никто не собирался.
Между тем замена платформы меняет работу независимо от намерений: другой продукт устроен иначе и закрепляет иные правила. Разница лишь в том, будут ли эти правила выбраны сознательно или сложатся из частных решений внедренцев.
Как работа идёт фактически на каждом ключевом участке — по проходу пути, а не по регламенту. Какие сложившиеся особенности подлежат сохранению и почему именно они. Какие обходные пути возникли как обход ограничений прежней системы и вместе с ней уходят. Какие правила система будет закреплять: согласования, полномочия, момент признания, признак завершённости. По какому признаку через полгода после запуска будет видно, что работа изменилась к лучшему. Кто в компании отвечает за содержание решений на каждом участке.
Как это разбирается
Замена учётной системы — тот случай, где одной встречи недостаточно. Переносить или пересматривать предстоит каждое правило, а значит, требуется восстановить фактическое устройство работы целиком. Это работа OFA Deep.
Это организовано так.
Фактическая карта работы из записей систем. Прежняя учётная система за годы накопила журнал: каждое действие с исполнителем, объектом и меткой времени. Из журнала восстанавливается ход процессов, который был в действительности. Разница между регламентом и практикой здесь получает численную величину вместо оценки на глаз.
Пять проверок над восстановленной картой. Где стоит ограничение, определяющее темп всей работы. Какова доля возвратов и переделок. Хватает ли управляющему уровню ёмкости для потока отклонений, который на него приходит. Как соотносятся незавершённая работа, время прохождения и пропускная способность каждого узла. Совпадают ли предписанные права решения с фактическими — кто по регламенту решает и кто решает на деле. Каждая проверка даёт измеренную величину и указывает на конкретный узел.
Разделение сложившегося на сохраняемое и подлежащее пересмотру. По каждому правилу определяется происхождение: часть возникла как обход ограничений прежней системы и уходит вместе с ней; часть представляет собой накопленный дрейф; часть — сознательное решение, составляющее преимущество компании. Без такого разделения перестройка задевает всё сразу, и потери обнаруживаются после запуска.
Два-три различимых варианта целевого устройства. Варианты расходятся по существенному: где остаётся точка решения человека, какие полномочия получает машина, как проходит поток через ограничение. К каждому прилагается цена компромисса. Выбор остаётся за руководством компании — в этом и состоит смысл того, чтобы вариантов было несколько и чтобы они различались по тому, что руководство обязано решать само.
План перехода. Из разницы между нынешним и выбранным устройством выводится перечень работ и их последовательность, а темп сопоставляется с тем, сколько изменений компания способна провести одновременно.
Результат разбора — техническое задание, где каждое правило имеет основание, и порядок работ, выведенный из связей между ними. Это тот материал, которого у подрядчика по внедрению нет и быть не может: он работает с описанием, которое ему передали.
Business Integrator