Ну вот нас и предупредили.
Конфигурация 1:С Управление производственным предприятием (далее УПП) верой и правдой служила нам с 2004 года. По данным фирмы 1С пользователями приобретено 31726 комплектов УПП, опубликовано 6459 внедренных решений на базе этого продукта.
И тем не менее – «все проходит». Вот и эра УПП завершается.
А что делать дальше? Вариантов довольно много:
- А ничего. Звучит парадоксально, но если в УПП ведется специфический управленческий учет и он полностью покрывает ваши потребности, то можно спокойно работать на УПП и дальше. Некоторые компании и на 7-ке работают до сих пор. Да, со временем возникают технические проблемы, но до какого-то момента они вполне решаемые.
- Перейти на 1С:Бухгалтерию. Вариант подходит для тех, кто вел в УПП только регламентируемый учет и не хочет ничего больше. 1С:Бухгалтерия очень толерантна к пользователям – бухгалтерам и работать в ней будет просто и приятно. Разумеется, этот вариант подходит, если нет сложного распределения затрат и расчета себестоимости.
- Перейти на 1С:Комплексная автоматизация. Этот вариант подходит, если кроме регламентированного учета, требуется вести складской учет, торговлю, заработную плату, кадровый учет в единой базе. Сложный производственный учет и расчет себестоимости и здесь не поддерживается.
- Перейти на 1С:Управление холдингом. Этот вариант для организаций, которые имеют сложную холдинговую структуру, которым необходимы в единой системе автоматизации корпоративные функции: консолидация финансовой отчетности по группе компаний и корпоративные налоги, корпоративное бюджетирование, сбалансированная система показателей и бизнес-анализ, управление мастер-данными и корпоративные закупки, управление активами, инвестиционными проектами и рисками, централизованное казначейство. Регламентированный учет при этом основан на 1С:Бухгалтерии и, соответственно, не поддерживает сложного распределения затрат и расчета себестоимости.
- Перейти на 1С:ERP Управление предприятием (далее ERP). Вот мы и добрались до сложного производственного учета. Если УПП работает у вас «по-настоящему», обеспечивая учет производственных операций, долгосрочное и краткосрочное планирование, бюджетирование, детальный учет затрат и сложные механизмы распределения затрат на выпуск, а также сложный расчет себестоимости, то практически единственным вариантом остается переход на ERP. Про этот вариант мы расскажем подробнее в нашей статье.
- И вишенкой на торте: если пункты 4 и 5 про вас – то целесообразно воспользоваться программным продуктом 1С:ERP. Управление холдингом.
А теперь главное: все, что написано выше, написано исходя из тех функций, которое покрывает УПП на настоящий момент. Но если исходить из этого принципа, то в результате мы получим замену одного продукта на другой, не приобретя при этом ничего сверх уже существующего.
У нас отличные новости! Данная ситуация хорошо подходит для того, чтобы оторваться от привычного и «помечтать о высоком». Можно не просто заменить существующие функции чем-то другим, а расширить само пространство автоматизации:
- Вели только регламентированный учет – после перехода на новый продукт навели порядок в складском учете.
- Вели учет в разрозненных программах – осуществили синтез различных учетных функций в единой базе.
- Собирали данные от филиалов в виде файлов Excel – организовали автоматический сбор и обработку данных с учетом внутригрупповых оборотов.
- И так далее! У каждого своя высокая мечта и вынужденный переход на новый продукт может обернуться новыми горизонтами развития.
А теперь подробнее рассмотрим вариант перехода с УПП на ERP.
Проектная технология внедрения
Прежде, чем говорить про переход с УПП на ERP, давайте коснемся технологи внедрения. Внедрение ERP целесообразно производить по проектной технологии. Просто перенести данные типовым переносом и далее работать – вариант, который имеет право на жизнь. Однако, за счет того, что системы разные и в плане организации НСИ, и в плане методологии ведения учета, то прежде чем приступать к переносу данных, обучению и запуску необходимо выстроить концепцию – модель будущей работы, определить структуру всех основных справочников системы: Виды номенклатуры, Номенклатура, Партнеры/контрагенты, статьи расходов, направления деятельности и т.д.; определить стратегии складского учета, серийного учета и т.д.
Внедрение новой системы – это, как правило, момент переоценки модели старой системы, анализ узких мест, что не устраивает, какой информации и разрезов аналитики не хватает и т.д.
Должны быть проведены работы по анализу возможностей/функционала новой системы, чтобы заранее понять и определить, что будет использоваться и как. Чтобы это не делать в процессе запуска. Иначе желание использовать дополнительный функционал спонтанно в момент начала работы может привести к значительным переделкам структуры ведения НСИ, повторной загрузке начальных остатков/справочников или значительной переделке модели, задержке запуска, что может повлечь потерю интереса, панику или запуск вообще может не осуществиться.
Так как рассказ про технологию проектного внедрения не является целью данной статьи, то мы лишь обозначим основные этапы работы:
1. Определение границ проекта – учетные блоки, подлежащие автоматизации. По каждому блоку необходимо собрать требования, определить имеющиеся бизнес-процессы, собрать все отчеты, документацию, которая оформляется, анализируется.
2. Анализ текущей справочной информации на предмет ее адаптивности к требованиям, соответствия структуре НСИ новой системы. Анализ функционала ERP – все ли операции, требования можно реализовать, выявить несоответствия, определить варианты их обхода и по каждому несоответствию из проработанных вариантов выбрать наиболее оптимальный.
3. Анализ переносимой НСИ, данных системы, которые лягут в основу переноса остатков. Насколько они корректны, должны ли они быть исправлены в старой системе до переноса, либо перенос осуществлять через промежуточные файлы, которые пользователями дозаполняются до загрузки.
4. Разграничения прав и ролей. Есть разные методики работы: в некоторых случаях пользователям сразу дают полные права, а потом по мере стабилизации системы при запуске производят корректировку и ограничение прав; либо сразу предусмотреть все необходимые ограничения.
5.Формализация концепции системы - все полученные данные и договоренности необходимо систематизировать и сформировать согласованный документ. Это важный момент, т.к. в процессе опытной эксплуатации можно будет обратиться к данному документу, чтобы проверить или урегулировать спорные вопросы.
6. Реализация доработок. Если было принято решение какие-то несоответствия устранять созданием обработок, отчетов или изменением алгоритмов, то до начала работы в системе необходимо сделать эти изменения. Также на этапе реализации производится подготовка (адаптация) обработок переноса НСИ и остатков, пробные переносы.
7. Важный этап – обучение. Обучение следует проводить в контексте для каждой группы пользователей, исполняющих одинаковые обязанности, только то, как они должны работать в системе.
8. И вот только тогда, когда проведена подготовка, сделана вся адаптация системы и обучены пользователи, производится перенос данных и начинается опытная эксплуатация. Вот теперь в режиме реального времени пользователи, чей функционал переходит в новую систему, вводят данные, формируют отчеты уже в новой программе.
И хотим обратить внимание на то, что на всех этапах участвует не только команда внедрения (неважно внутренняя или внешняя), но и сотрудники предприятия. Именно сотрудники, принимающие решения, то есть руководители среднего и высшего звена, определяют, что должно быть в системе для управления предприятием. Именно они принимают решение о структуре НСИ, о том, какой вариант обхода того или иного несоответствия принять. Именно они принимают доработки и проверяют, соответствуют ли они их требованиям.
Варианты перехода
Есть два вариантов перехода из одной системы в другую в плане одномоментности, со своими достоинствами и недостатками:
|
Запуск одновременно всех блоков |
Постепенный переход |
|
- |
значительно отложенное получение осязаемого результата |
небольшие сроки внедрения функционально законченных блоков; краткие сроки, когда можно получить осязаемый результат по блокам внедрения |
+ |
+ |
с одного момента получаем систему, готовую к эксплуатации всех блоков исключены нюансы постепенного запуска: разные сотрудники работают в разных системах; т.к. работа параллельно производится в двух системах, приходится определенное время сверять данные в них; в процессе постепенного запуска по ряду операций изменяются инструменты отражения; |
требуются дополнительные подстраховки – обмены (для исключения двойного ввода данных между системами); «заглушки»/условности – когда до запуска, например, блока «Производственный учет» выпуск готовой продукции отражается не свойственной операцией – «Оприходование товаров»; до регламентированного или полного управленческого учета не контролировать полную стоимостную оценку ТМЦ и т.д. |
- |
- |
из-за длительного срока подготовки (особенно на крупном предприятии) может произойти выгорание команды |
практика показывает, что получение результатов по первым блокам внедрения приводит к энтузиазму и ускоряет работы по внедрению последующих блоков |
+ |
- |
если в проектировании по объективным или субъективным причинам допущена неточность, то корректировка может затянуть общий запуск; потребовать существенных переделок |
на 1-м же этапе происходит тестирование спроектированной НСИ, вносятся необходимые корректировки – они еще не так сильно влияют на результат, т.к. есть дублирующая система
|
+ |
- |
длительный процесс подготовки |
сложнее анализировать взаимосвязь данных между блоками при проектировании; сложнее получать целостную картину будущей системы |
- |
|
|
обкатав на первом этапе технологию, методику, взаимодействие, терминологический аппарат, команда работает более продуктивно |
+ |
За 24 года (столько существует наша компания на рынке ИТ-услуг) переводом с одних систем на другие мы испробовали разные методы внедрения. Каждый из них подходит для различных вариантов.
Одним запуском целесообразно запускать «моносистемы» – «ЗУП», «УТ», «БП» и т.д.
Постепенный переход целесообразно использовать для комплексных систем, в частности при переходе из УПП на ERP. Если все-таки использовать в этом случае методику одномоментного запуска, нужно помнить о возможных рисках:
- риск полной остановки предприятия, если одновременный переход происходит без дублирования всей информации в старой системе;
- риск постоянной сверхурочной работы в течение 3-6 месяцев при дублировании данных.
Какое есть инструменты перехода
Какие же есть типовые инструменты, облегчающие переход от УПП на ERP?
- Помощник перехода – обработки, которые позволяют произвести перенос настроек, НСИ и начальных остатков. При этом начальные остатки можно переносить как по данным бухгалтерского, так и управленческого учета.
- Механизм синхронизации через универсальный формат – используется для обменов; позволяет синхронизовать НСИ, производить перенос документов.
На реальных проектах и тот, и другой инструмент требуют, как правило, адаптации к системе Заказчика. УПП часто бывает кастомизирована таким образом, что перенос данных из типовых хранилищ невозможен. Или может обнаружиться, что данные в УПП нужно выбирать сложным образом. Или остатки в УПП некорректны и времени и сил на приведение системы к должному виду нет. В такой ситуации может спасти механизм переноса данных через промежуточные файлы – например, шаблоны Excel.
Есть ограничение и у механизма синхронизации по документам, который предусмотрен как раз для поэтапного перехода. Это невозможность двухстороннего обмена одним и тем же видом документов. Представьте, что на первом этапе в ERP переводятся только центральные склады, а цеховые кладовые – на последующих этапах. Следовательно, документы движения по центральным складам пользователи первично отражают в ERP, и в УПП они должны переносится, а по цеховым кладовым – первично отражаются в УПП, а для целостности учета должны переноситься в ERP. При этом используемые виды документов одни. Этот момент придется доработать в обмене.
Есть несколько механизмов обмена
Рассмотрим чуть подробнее возможные механизмы обмена:
- Штатный механизм синхронизации
- Собственная разработка обмена, созданная при помощи конвертации данных.
- Сервисная шина данных.
При выборе вариантов необходимо учитывать, что обмен для осуществления постепенного перехода на ERP - это временное явление. После полного перехода всех блоков обмен прекратит свое существование.
Поэтому использовать, например, сервисную шину данных, которая предназначена для регулярных, постоянных обменов, в данном случае нецелесообразно. Все равно как палить из пушки по воробьям: и птичек жалко, и ядра дорогие.
Остаются штатный механизм или собственная разработка. Штатный механизм синхронизации хорош, если глобального пересмотра НСИ не происходит. Тем не менее практически на каждом проекте бывают определенные особенности обмена между системами. Например, может происходить преобразование справочника Номенклатура: либо добавление/систематизация характеристик, либо добавление/систематизация серийного учета, либо вообще полный пересмотр справочника. Поэтому штатный механизм приходится дорабатывать или в принципе писать свой собственный обмен.
Сроки перехода
Исходя из всего, написанного выше, приходится сделать вывод, что переход с одной системы на другую не может произойти мгновенно: сегодня работали в одной системе, а завтра уже в другой.
Наш опыт говорит следующее:
Срок запуска первых этапов (оперативный контур) может составить от 3 до 6 месяцев. 3 месяца – это самый хороший случай, когда практически нет доработок, используется штатная синхронизация, Заказчик имеет 100% мотивацию и заинтересованность, процесс согласования происходит «моментально».
Блок производственного учета может занять от 6 месяцев до года. Срок внедрения производства может быть и больше в зависимости от сложности производства и количества лиц, принимающих решения.
Регламентированный учет (при условии готового оперативного контура) занимает от 4 месяцев.
Подготовка обмена, в случае если не подходит штатный механизм, может занять от 2 до 3 месяцев, с учетом подробной проработки Технического задания и 3-х этапного тестирования. Дальнейшая его доработка может занять от 1 -1,5 месяцев.
Таким образом, в случае последовательного перехода, процесс может занять от 1.5 до 2 лет. Для одномоментного перехода срок может оказаться тем же, только работы по длительности будут перераспределены внутри этого срока.
Итого
Как видим, сроки перехода с УПП на ERP довольно-таки существенны, поэтому переход надо планировать заранее.
Лучше «приготовить сани летом», иначе переход в последний момент обязательно приведет к тому, чтобы перейти хоть как-то: без улучшений, без основательной проверки работоспособности новой системы, с особенностями типового обмена и т.д. и т.п.
При этом велик риск оказаться в ситуации, когда старое уже не работает, а новое еще не работает.
К тому же стоимость перехода во время всеобщего бума вероятно будет выше (по совершенно объективным обстоятельствам), чем при переходе за 4-5 лет до события.
Какой бы вариант вы не выбрали, мы желаем вам успехов на избранном пути!