Сегодня «модным» запросом рынка становится технология «переезда» с SAP (и аналогичных западных решений) на 1С ERP в кратчайшие сроки, и речь идет о считанных месяцах (месяца 3-4). Более того, у некоторых заказчиков есть желание провести все еще быстрее. Но логика обстоятельств не позволяет играть со сроками, так или иначе, и заставляет считаться с объективными трудностями этого процесса.
Даже при выборе крайне оптимизированной по временному критерию технологии есть минимальные сроки, «сжать» которые становится предельно дорого. Другими словами, каждый дополнительный день экономии по времени потребует вложений ресурсов с растущим в прогрессии коэффициентом. Например, 1-й дополнительный день экономии срока («сжатия графика») потребует + 200 человеко-часов, 2-й день —+500 человеко-часов, 3-й, соответственно, + 900 и т. д. и т. п.
По минимально необходимому составу работ скоуп технологии состоит из двух технологических этапов (направлений) работ, которые нужно провести для осуществления быстрого перехода на 1С:
-
Разворот и настройка сред и информационных баз 1С, в т. ч. в рамках подготовки для старта — миграция нормативно-справочной информации и начальных остатков по учету на дату старта;
-
Обучение пользователей, в т.ч. администраторов со стороны Заказчика автоматизации и их «погружение» в новую среду.
Также нужно оговориться, что в практике автоматизации обычно еще встречаются такие этапы: обследований, проектирования, разработки/доработки решений вендора, а также всяческих опытных и опытно-промышленных эксплуатаций и сопряженных с ними тестирований. В данном случае мы не считаем их критичными и поэтому здесь не рассматриваем, т. е. абстрагируемся.
При практическом применении оптимизированных проектных технологий перехода с SAP на 1С ERP мы успели столкнуться с целым рядом серьезных проблем, которые раньше либо не выделялись, либо были в управляемом русле проектного внедрения.
I. Различия в архитектуре решений
Во-первых, нужно отметить кардинальные различия в парадигмах технических решений (платформ), что влечет за собой «трудности перевода» для будущих пользователей и стейкхолдеров, например укорененное восприятие будущей Системы как набор нескольких разных инстансов, которые связаны между собой. Часто возникают вопросы типа: «А это будет реализовано в каком модуле?» или «А можем ли мы запустить сначала вот этот модуль?»... Очевидно, что только по прошествии некоторого времени у специалистов от бизнеса заказчика в сознании начинает проявляться «другая картинка», т. е. картина про 1С ERP.
Парадигмы и восприятия
Все пользователи и представители ИТ-службы заказчика привыкли рассуждать некоторой совокупностью терминов и понятий. Также в их головах сложилась какая-то устоявшееся картинка, которая никак не совпадает с картинкой, которую проецирует вселенная 1С. Так, например, в SAP бухгалтерские проводки записываются в простую таблицу, а в 1С они укладываются с применением принципа «двойной записи». Или пользователи привыкают употреблять в смысле затратных счетов выражение «тридцатые счета», или вместо операций/документов используется термин «трансакции», или и или и прочее, прочее.
Понятийный аппарат, помноженный на привычку, приводит к тому, что «трудности перевода» затрудняют коммуникацию значительное время, это также накладывает отпечаток на обучение будущих пользователей Системы и требует большего времени для адаптации и привыкания к новой парадигме. Нам потребовалось примерно в 2 раза больше времени на обучение и погружение пользователей заказчика от расчетного.
Консистентность исторических данных
В силу модульности семейства SAP для различных складов заказчик использовал отдельные информационные базы, договоры учитывались в одном инстансе, а бухгалтерские проводки в другой базе. При сливании всех данных в единую ERP-систему возникает, как правило, много стыковочных противоречий. Как в указанном примере, оказалось, что для двух разных складов использовались разные номенклатурные карточки для материалов с одинаковым кодом артикула. Нужно всегда закладывать время на разрешение такого рода «рассинхрона». В начале проекта это совсем неочевидно и всем участникам автоматизации кажется, что такой риск исключен. Но это не так...
Различие в структуре данных и нормативно-справочной информации (НСИ)
При различии архитектурных парадигм возникает и логичная трансляция на структуру данных и НСИ. В семействе SAP существует своя система справочников (Заводы, места возникновения затрат (МВЗ, Бизнес-единицы и т. д.). Понятно, что заказчик методологически подстраивается под стандарт, который транслирует вендор. Так выстраивается бизнес-практика по закону Конвея, который можно трактовать как структурно, так и содержательно применительно к бизнесу.
Например, мы сталкивались с тем, что бухгалтерские службы из-за отсутствия субконто счетов и статей расходов в техническом решении SAP брали в качестве детализации в учете субсчета и, соответственно, условный 20 счет мог иметь 20-30 субсчетов. Также для учета по центрам финансовой ответственности нередко используются МВЗ, однако это не вполне корректно с точки зрения лучших практик. При долгом вынужденном использовании «смежных» справочников происходит наполнение «разновидовыми» сущностями, т. е. могут рядом уживаться и ЦФО, и производственные площадки в уже названном справочнике МВЗ.
Таким образом, при переходе на структуру НСИ в 1С мы получаем аналитический «фьюжн», который необходимо разложить по видам аналитики и трансформировать бизнес-практику использования справочников для аналитики.
Автономность модулей
В данном случае под автономностью мы понимаем лишь относительную независимость одного модуля SAP от других. В решении 1С многие документы и аналитические разрезы присутствуют в разных функциональных областях. Например, документ, отражающий факт закупки материального ресурса, в котором содержится первичный учетный документ (УПД), сначала обрабатывается представителями снабженческой функции, далее с ним работают складские работники, затем работники бухгалтерии и, наконец, финансовые службы обращаются к этому документу для осуществления оплаты по обязательствам перед контрагентом. В SAP же наоборот: документы (трансакции) в одном модуле будут связаны с трансакциями другого посредством интеграции. И у пользователей, которые привыкли к логике и архитектуре SAP, не укладывается взаимозависимость и все особенности одновременного доступа к одному и тому же документу со стороны нескольких функциональных групп сотрудников. Это накладывает вполне предсказуемое избыточное желание к ролевой модели по доступам и локализации прав по редактированию документов.
Например, стейкхолдеры высказывают желания ограничивать доступы к одним и тем же документам Системы для разных групп/профилей пользователей, что реализовывать зачастую трудоемко. А проблемы такого плана решаются простыми организационно-управленческими методами (разграничением полномочий, инструкциями и производственной дисциплиной).
Также описанная особенность по автономности оказывает влияние на репликацию и изолированность НСИ. Например, при миграции данных по НСИ в части договоров с контрагентами организации пришлось столкнуться с ситуацией, когда в финансовом модуле отсутствовали договоры как таковые, однако присутствовали в модулях материального потока (закупках). Таким образом, было необходимо дополнительно синхронизировать данные по первичным учетным документам (трансакциями) с генерируемыми ими проводками и договорами с контрагентами.
Как-то нам пришлось столкнуться с кейсом, когда каждый склад учитывался в своем модуле SAP, и при миграции с одну информационную базу 1С по значительному числу МТР возникли «задвоения» по номенклатуре, т. е. артикул был одинаковый, а текстовое название элементов справочников было различным, что увеличивало путаницу для пользователей и вносило дополнительные трудности для групповых обработок по загрузке входящего потока от поставщиков. Далее по цепочке данный кейс доставлял дополнительные трудности при интеграциях и смежных процессах и наконец потребовал перепроектирования уже согласованных решений.
II. Методологический перфекционизм
Как уже отмечалось выше, бизнес-пользователи в исторических системах SAP были вынуждены прилаживать справочник счетов бухгалтерского учета и справочник мест возникновения затрат (МВЗ). Тем самым, когда у бизнес-пользователей появилась возможность вести свои аналитические разрезы в другой конфигурации, т. е. вместо двух справочников появились четыре и более специализированных справочников (счета, субконто, структура предприятия, статьи расходов и пр.), возникло широкое поле для возможных вариантов переконфигурации учета.
А чем больше вариантов для построения системы аналитик в едином процессе — тем больше времени нужно для проработки. Конечно, есть лучшие практики и методологические рекомендации вендора и т. д., однако нередко у конечных пользователей возникает искушение найти окончательное и идеальное решение своих методологических вопросов, особенно в свете долгой жесткой обусловленности и невозможности «расправить крылья», что далее приводит к долгим обсуждениям, прениям и даже спорам со смежными функциями бизнеса. В конечном счете мы столкнулись с достаточно длительными процедурами оптимизации методологии со стороны заказчика. Это привело к сдвигам плановых сроков по миграции из SAP в 1С, что несомненно является серьезной проблемой для хода проекта внедрения.
Таким образом, чтобы управлять этим серьезным риском, напрашивается вопрос: как оптимизировать методологию быстрее? На опыте достаточно широкого ряда внедрений мы поняли, что просто «в лоб» данную проблему не решить. Да это не говорит о том, что не нужно предпринимать усилий для убыстрения выстраивания методологии, но вместе с тем, ставку нужно делать на нетривиальные подходы.
Проблема «зависшего» решения методологии может, в частности, решаться следующим способом: разнесение целостного технического решения на очереди реализации; так в согласованный момент, когда уже нельзя откладывать начало работ по техническому исполнению решения (разработки или доработки ПО), производится «отсечка» открытых вопросов и запускается первая очередь реализации. Остальное — открытые вопросы — относятся на вторую очередь и развитие Системы.
В итоге мы можем поступательно двигаться в реализации проектного внедрения, пусть и не теми темпами, которыми планировали.
III. Администрирование НСИ
В любом внедрении технических решений класса ERP задача управления и централизации НСИ является основополагающей. Как правило, основное бремя забот ложится на плечи специалистов ИТ-службы или проектного офиса заказчика. При использовании «сжатой» проектной технологии тема администрирования НСИ становится архикритичной.
Необходимо прямо «с колес» выстраивать ролевые модели, в частности, для редактирования сквозных справочников, таких как Номенклатура, Контрагенты, Договоры и аналогичные.
Также необходимо перманентно отслеживать качество заполнения информации в шаблонах загрузки данных и НСИ для миграции данных с исторических модулей SAP. Например, нам приходилось сталкиваться с отсутствием методологической поддержки пользователей в заполнении шаблонов перегрузки, что выливалось в многочисленные загрузки одной и той же информации в целевую Систему. В силу технических особенностей 1С ERP в большинстве случаем при наличии ошибок в шаблоне по нескольким позициям с точки зрения экономии дальнейших ручных выверок проще сделать новую загрузку всего массива данных шаблона.
Опять же мы понимаем, что дополнительные итерации одних и тех же операций приводит к задержкам проектного внедрения.
IV. Вопросы разграничения полномочий, ролей, задач между бизнес-пользователей и ИТ/проектным офисом со стороны заказчика
Нередко возникают смежные вопросы, которые трудно отнести к той или иной юрисдикции. Очевидно, что вопросами проектирования технического решения должны заниматься представители ИТ-функции заказчика, вопросами прохождения проектных контрольных точек и процессами — представители проектного офиса, а постановкой бизнес-задач и пользовательских требований — ключевые игроки со стороны функций бизнеса заказчика.
Однако не всегда и не всем это очевидно. Более того, встречаются вопросы, которые практически невозможно отнести к одной юрисдикции из описанных выше. Так, мы сталкивались с вопросами ограниченности информационных систем, например по микро измерениям или микро нормированию. Или бывают случаи с детализацией взаиморасчетов по материальным позициям. Так или иначе, но бизнес-практику необходимо «прилаживать» к 1С, как и в случаях с подпрограммными продуктами SAP.
Но ключевым здесь является тот арбитр, который сможет на стороне заказчика принять окончательное решение. Чтобы найти такого арбитра, порой необходимо тратить дополнительные время и усилия, что также негативно сказывается на сроках проектных внедрений.
V. Аспекты восприятия
Как уже отмечалось выше, из кардинальной разницы в парадигмах обеих вселенных вытекает необходимость к «упаковке» и повышению эффективности технологии обучения пользователей новому продукту. По опыту мы сталкивались с тем, что восприятие рядового пользователя конечно, поэтому необходимо закладывать еще больше времени и усилий для полноценного и быстрого осваивания новых навыков работы с 1С. Мы разработали несколько комплексных технологий для увеличения плотности и эффективности осваивания нового материала пользователями.
В итоге мы имеем достаточно серьезный вызов со стороны рынка, под который разработали и отточили в реальных живых условиях методологию внедрения с учетом особенностей человеческой природы. Да, пришлось столкнуться с рядом незапланированных трудностей, но постоянно оптимизируя подходы и технологии, мы сумели добиться положительных результатов.
