Pull to refresh

Comments 7

Вы забыли написать про главное — ЗАЧЕМ.
Цель внедрения какая была?
Достигнута она?
В чем измеряется цель вашего проекта? Как изменились показатели компании после внедрения и что это за показатели?
Я скорее технический специалист, чем бизнес-консультант. Данная статья отвечает КАК нужно переходить на новую систему.
Причины перехода на новую программу остались за рамками статьи, только вскользь было упомянуто про то, что старая программа больше не удовлетворяет потребности бизнеса. И если говорить про конкретный проект, то решение созрело и было принято бизнесом до меня, от меня требовалось только осуществить переход.
Цели написания статьи — показать новый способ внедрения, в противовес так называемому большому взрыву. Так получилось, что две одинаковые фирмы выполняли внедрение 1С практически одновременно. В одной выполнялось большим взрывом — т.е. с 1 января все пользователи перешли на новую систему. А в другой, где работал я со своей командой, управляемым взрывом — перевод по отдельным рабочим местам. Разница была в том, что первая фирма на месяц остановила отгрузки клиентам, т.к. оказалось что программа была местами не доработана, вторая фирма ни на день (и даже не на час) не прекращала свою работу. И вот хочется чтобы мой опыт пригодился…
Внедрять ERP-систему отдельными рабочими местами можно и, даже, я сказал бы, нужно. Вопрос лишь в том, какими местами.
Разумеется нельзя разрывать цепочку продажи-закупки-склад.
А какая проблема внедрить управление договорами или, например, управление платежами без внедрения склада? Это не связанные вещи.
Наверно, текст статьи я написал несколько сумбурно и не передал основную мысль. Попытаюсь это сделать заново.
Всего существует две полноценные рабочие базы. Одна база — это старая программа, другая это новая программа. Между ними настраивается двухсторонний обмен. Все изменения сделанные в одной базе передаются в другую. Не важно какие пользователи в каких базах работают.
Сложность тут в том что это технически трудная задача, но она ничто по сравнению с организационной задачей при внедрении системы для нескольких сот пользователей. Да, нужно потратить несколько месяцев для наладки обмена, зато получаем выигрыш при внедрении: безопасность перехода и достаточно быстрая скорость перевода. В данном проекте была филиальная структура, мы с фин. директором заказчика ездили по филиалам и внедряли программу — неделя в одном городе, неделя в другом. Но через некоторое время собственникам фирмы надоело постоянное отсутствие фин.директора, т.к. он нужен был в Москве. Было принято решение внедрять удаленно — через Skype. Скорость внедрения резко выросла, каждый день я переводил один филиал, а через пару недель мы отключили старую программу (это был RS-Balance)
Со справочниками понятно, а прочие данные мигрировали на уровне первичных документов, или использовались механизмы синхронизации регистров? Как обрабатывались случаи изменений задним числом, когда нужно делать перепроведение документов для выравнивания остатков товаров по партиям? Как синхронизировалась бухгалтерско-финансовая часть учета (ОС, зарплата, банк-касса-подотчет)?, Там ведь довольно много сложных документов и операций, да и паника при расхождениях сумм на счетах сильнее, чем при расхождении количества на складах.

Я пытался практиковать такой подход. С товарно-складским учетом все более-менее просто, некоторые филиалы работали в старых системах учета годами, и это было даже проще, чем внедрять и поддерживать единую распределенную систему. А вот с финансовым учетом кроме как взрывом не получалось.
Если говорить про проект 2013 года, то перевод был из RS-Balance, там несколько другие были объекты, например, там не было регистров и кроме того, там редактированием задним числом невозможно. И кстати это значительно облегчило жизнь при переходе…
В случае более ранних проектов, например, в 2008 году переводил с 1С 7.7, то передача осуществлялась справочник в справочник, документ в документ, а бухучет велся в отдельных базах, и после перехода он также продолжался вестись в отдельных базах. Более того у меня на практике так сложилось, что клиенты от несколько сот пользователей в базе всегда вели бухучет в отдельных базах.

Согласен, применять такой способ для всех случаев жизни не оптимально. Его выгодно применять только на тот контур программы, число пользователей которого очень большое, а их деятельность высокооперативна (например непосредственно обслуживают покупателей, фронт-офис). Если это, например, финансовый блок с небольшим количеством пользователей системы, в нем мало сотрудников, остановка их работы на несколько дней существенно не повлияет на работу компании, то можно переводить обычным способом — остановить старую программу, запустить новую или параллельно вести учет в течении месяца в двух программах…
Sign up to leave a comment.

Articles