Внедрение 1C:ERP Управление предприятием в компанию НПО "ЭкоФуд"

1. Описание

Компания НПО ЭкоФуд работает на рынке под несколькими торговыми марками, такими как Icedream (https://icedream.ru/); Miller&Miller (https://millernmiller.com/); Global Food Ingredients (Джи Эф Ай Рус (https://gfi-rus.com/)). Исторически сфера деятельности компании была торговля. Но позднее в компании было принято решение открыть собственное производство. Сейчас компания представлена на рынке четырьмя направления деятельности: производство соков, сиропов, десертов; производство сухих смесей для мороженного; производство муки и пудры; торговля сопутствующими товарами и оборудованием.

Исторически сфера деятельности компании была торговля, и оперативный учет велся в торговой программе 1С:Управление торговлей 10.3 с добавленным в нее блоком CRM 2. Программа, в которой объединены в одной базе оба модуля называется  1С:Управление торговлей и взаимоотношениями с клиентами (далее УТиВСК). В программе был настроен обмен с 1С:Бухгалтерия 8 для сдачи регламентированной отчетности.

В связи с тем, что в процессе работы компания открыла собственное производство, торговая программа УТиВСК перестала отвечать требованиям компании, т. к. для производственного учета она абсолютно не предназначена. Силами программистов был выполнен ряд серьезных доработок программы для отражения производственных операций. На момент выполнения данных доработок у 1С уже была программа 1С:Управление производственных предприятием (далее УПП), но по неизвестным причинам программисты решили не выполнять переход на более подходящее решение, а реализовать производственных блок в программе УТиВСК собственными силами. Естественно это колоссальный объем работы, даже для команды программистов, т. к. чтобы написать собственную подсистему необходимо изучить общепринятые методики производственного учета, бухгалтерский и налоговый учет производства. Т. е. овладеть эталонными знаниями совершенно из чуждых программисту областей знаний. Поэтому где-то подсматривая, где то принимая собственные решения производственный блок был написан с нуля и запущен в работу. Естественно при маленьких сроках разработки и отсутствия методических знаний в предметной области при разработке были допущены серьезные методические ошибки, а также реализованы не все возможные производственные операции. 

Был реализован только минимальный функционал, востребованный компанией «здесь и сейчас». Учет полуфабрикатов, производство продукции из давальческого сырья, передача сырья в переработку реализованы не были, и даже не закладывалась база под это. Тем не менее доработки были достаточно серьезны, чтобы обновлять программу стало очень трудно и тяжело. После обновлений многие доработки затирались или переставали работать. Поэтому программа обновлялась как придется, часть модулей бралось из новых версий, часть так и оставалось старыми. Т. е. от документированный программы УТиВСК уже не осталось ничего, она могла повести себя совершенно не так как ожидает от нее специалист. 

В программе работали до нашего прихода порядка 8 лет, и за это время в ней накопилось огромное количество учетных ошибок, отчасти вызванных в ошибках доработках, сделанных ранее. Остатки сырья, продукции половина горят красными минусами, партии подбираются не корректные, при проведении документов срабатывают какие-то непонятные и недокументированные контроли, дописанные программистами, но видимо уже работающие не так как ожидается. При этом система продолжала обмениваться с бухгалтерской программой, и выверка данных после обмена занимала колоссальное время – данные загружались не корректно, документы не проводились, справочники многие были не то что задублированы, а просто многократно продублированы одни и те же элементы с одним и тем же названием могли встречаться до 15 раз. 

Мы пришли в эту компанию как обслуживающая организация, чтобы оказывать поддержку пользователям, обновлять программы, администрировать обмен данными, выполнять доработки и решать учетные задачи. Но после месяца работы мы поняли что каждодневный аврал и стресс это не есть то чего хотели бы все. Во-первых почти все время 2-х специалистов уходило на поддержку одного этого клиента, а ресурсы не безграничны. Во-вторых, было четкое понимание что мы никак не можем изменить ситуацию, даже если всей компанией бросимся работать и разгребать ошибки в доработках, в учете. За 8 лет в обоих базах накопилось столько ошибок, нестыковок, каких-то богом забытых доработок, которые уже только мешают, что разгрести эту кучу можно было только одним путем – закрыть работу в этой базе и поставить рядом пустую чистую базу без каких-либо доработок, перебив в нее начальные остатки и начать работу с чистого листа. Т. е. это нормальная практика и мы часто предлагаем такое клиенту, когда видим что ситуацию в действующей базе исправить не возможно. Но тут делема, читая программа УТиВСК не подходит для ведения учета. 

УПП устарела морально и внедрять ее сейчас, когда она на ладан дышит – закапывание средств. Остается 1С:ERP Управление предприятием (далее ERP), но расходы на внедрение колоссальные и не предусмотренные никакими бюджетами клиента. Поэтому по результатам месяца обслуживания текущей системы мы написали клиенту заключение, т. к. считаем, что такую ситуацию нужно обнародовать, чтобы клиент сам принял участие в судьбе своей главной программы в компании. Текст заключения приведен ниже.

2. Заключение по результатам месяца обслуживания

2.1 Цель данного заключения

Предупредить компанию о возможных последствиях и проблемах

2.2 Описание

В результате обслуживания базы УТиВСК в течение месяца и после более глубокого изучения всех доработок программы и данных базы мы пришли к выводу что дальнейшее развитие и эксплуатация данной базы данных является нецелесообразным и крайне затратным. В виду того что ряд доработок выполнены с нарушением стандартов разработки компании 1С и в нарушение внутренней логики типовой конфигурации УТиВСК, последствия трудно обратимы, в рамках текущих сценариев обслуживания.

Примерный срок эксплуатации базы на текущий момент: 8 лет

За данный срок у многих компаний даже при правильно поставленном учете в базе данных появляется рассогласованность данных в виду человеческого фактора и рекомендуется рассмотреть свертку базы и провести инвентаризацию разделов учета. Это нормально, и встречается повсеместно. Но в данном случает рассогласованность данных базы появилась не столько в результате человеческого фактора, сколько из-за некорректно выполненных доработок в прошлом, что привело к накоплению ошибок учета, о которых не знали сотрудники компании. Уже сейчас накопленный объем ошибок и не правильных доработок перешел на уровень, когда глобально устранить причины ошибок становиться слишком сложно и требует больших затрат времени, а в рамках сокращенного бюджета просто невозможно. В рамках бюджета можно устранять только следствия глобальных ошибок, сделанных ранее, т. е. как и предыдущие обслуживающие компании – работать по инцидентам. Работа по инцидентам увеличивает накопление старых ошибок, и приводит к образованию новых в прогрессии. Устраняя только следствия ошибок, а не их причины можно еще работать некоторое время, но это приведет к накоплению критической массы ошибок и нестыковок в учете и дойдет до той степени, когда данным программы уже нельзя будет доверять, а работа будет прерываться слишком часто, чтобы ситуацию можно было считать удовлетворительной.

2.3 Причины 

• Работа напрямую с программистом по инцидентам, без привлечения консультанта по программе; 

• точечные, не продуманные глобально, доработки;

• огромное количество доработок, которые опираются в своей функциональности на пользовательские данные (поиск объектов по наименованию, по коду), при изменении пользователем пользовательских данных (на что пользователь имеет полное право) доработки «отваливаются»;

• запущенность ошибок учета, несвоевременное их исправление (остатки по складам в разрезе серий просто удручают);

• попытки решить фундаментальные проблемы, связанные с тем что УТиВСК это программа исключительно для торговых компаний, силами одного программиста, вместо перехода на более подходящую изначально программу, в разработку которой вложены сотни миллионов рублей и сотни тысяч человеко-часов;

• слабая гибкость доработок, доработки работают только в текущем окружении, меняем окружение (хотим работать по давальческой схеме, хотим подключить онлайн-кассу, хотим начать вести учет полуфабрикатов и брака) и программа его уже не поддерживает, доработка собственными силам – космические траты;

• слишком серьезные и дорогие доработки, при маленьком бюджете на их поддержку (на реализацию нового функционала и его поддержку компания 1С тратит сотни миллионов рублей ежемесячно) реализация собственного производственного учета в программе, которая для этого не предназначена чтобы он был гибким и поддерживал все возможные схемы учета – сравнимые с 1С траты.

2.4 Прогноз 

В виду большого количества доработок и высокой степени рассогласованности данных, база УТиВСК все чаще будет приводить к простоям и выдавать ошибки. В связи со слишком большим количеством возможных комбинаций событий и данных, в результате которых возникают ошибки, предсказать или упредить это кардинальным образом невозможно. Любое изменение пользовательских данных (переименование или ввод новых складов, пользователей, подразделений, номенклатурных групп и пр.) должно быть согласовано с программистом, потому что гарантировано будет приводить к тому что доработки будут «отваливаться» и что хуже работать не корректно, поэтому программист должен быть извещен о намерении поменять пользовательские данные заранее чтобы быть доступным на дежурстве. Работая исключительно по инцидентам, не решая причин проблем данная ситуация будет усугубляться пока не приведет к полному недоверию данным программы. Работа не по инцидентам, а с выявлением глобальных причин ошибок и их устранение раз и навсегда по стоимости эквивалентна проекту по каждой задаче с полной переделкой всего хоть как-то косвенно связанного с задачей. Требования к квалификации специалистов будут расти, хотя и при текущей ситуации они выше «среднего по больнице», но за неимением их на рынке, отношения со специалистами будут складываться все хуже и каждый следующий обслуживающих специалист будет казаться хуже предыдущего. Текучка специалистов приводит к еще более поверхностному отношению к базе, а база данных – это сердце компании и чем дольше она служит, тем лучше в конечном счете для всех.

2.5 Пути решения

Есть 3 пути дальнейшего развития автоматизации в компании.

2.6 Путь 1 (самый правильный)

Готовиться к переходу на другую программу - 1С:ERP. Не вкладывать средства в текущую УТиВСК. При переходе на ERP учесть весь негативный опыт и внедрить на 95 процентов типовой функционал, т. к. он целиком отвечает требованиям организации. В 5% доработок входят косметические изменения, в частности редкие печатные формы, которых нет в типовой конфигурации 1C:ERP, внешние обработки заполнения табличных частей, а так же доработки, которые можно выполнить через новый механизм расширений конфигурации без модификации основной конфигурации. 

Полностью изменить подход к обслуживанию базы данных. Поддерживать конфигурацию в типовом состоянии постоянно, т. к. сфера деятельности обследуемой компании абсолютно типичная и полностью автоматизирована в типовом решении. При возникновении потребностей обращается не к программистам, а к консультантам или методистам по программе 1C:ERP, которые сначала проанализируют возможность решения задачи штатными средствами программы, которых множество, либо составят правильное задание на разработку программисту, которое не будет затрагивать критическую функциональность программы, такую как расчет себестоимости, партионный учет, контроль остатков и регистры учета и пр. 

При любых обращениях в обслуживающие организации акцентировать внимание на том, что необходимо решение задачи штатными средствами, без модификации конфигурации. Если обслуживающая организация предлагает выполнить модификацию конфигурации (доработку) требовать детального обоснования модификации с демонстрацией ограничений типового функционала. Потребности в глобальных изменениях конфигурации отправлять на линию поддержки клиентов компании 1С, с целью включения данной потребности в будущие плановые релизы. 

В случае обнаружения ошибок в типовом решении, перед тем как ставить задачу программисту, обратиться к консультанту (методисту) и убедится, что данное поведение действительно является ошибкой программного продукта и в первую очередь написать об этом в официальную техподдержку компании 1С, чтобы данная ошибка была зарегистрирована и исправлена в следующих версиях программного продукта. Запросить у консультанта способ обхода ошибки без модификации конфигурации. 

В случае невозможности обхода ошибки типовыми средствами и, если ошибка действительно критична и безотлагательна (что в типовых продуктах крайне редкое явление) внести исправления ошибки конфигурации собственными силами (поставить задачу программисту, через консультанта-методиста), обязательно вести учет таких исправлений и при выходе официального исправления от компании 1С, убирать из конфигурации собственные исправления, заменяя их на официальные исправления компании 1С. 

Регулярно обновляться (не реже раза в месяц). В случае выявления ошибки программы, сначала проверять наличие обновлений, при их наличии выполнять обновление, только если ошибка не ушла после обновления, обращается к консультанту. 

Доработку новой функциональности делать не до внедрения, а после начала работы на типовой программе (при условии, что программа изначально закрывает 95% потребностей). До внедрения нужно сделать минимум доработок без которых работать просто невозможно (хотя в вашей сфере таких доработок просто нет), все остальные необходимости в доработках будут выявляться в ходе работы. Перед выполнением доработки убеждаться, что такой функционал не запланирован в новой версии программы чтобы избежать создания дублирующего (альтернативного типовому) функционала. 1С:ERP в отличие от УТиВСК до сих пор развивается, и будет развиваться, поэтому если в ней сейчас чего то не хватает, то это может появиться после обновления и необходимость в «своих» доработках отпадет сама собой. 

Любые задачи по 1С в обслуживающие компании должны исходить от одного ответственного человека со стороны заказчика. Потребности отделов должны приходить к нему, он должен классифицировать, формулировать, отвергать лишнее, и только жизненно необходимое передавать на исполнение обслуживающей компании. Вести учет задач и доработок, четко классифицировать задачи по типам (ошибка учета, внешняя печатная форма, внешняя обработка и т. д.) и особенно уделять внимание задачам, требующим доработки типовой конфигурации. Доработка должна восприниматься как явление негативное, затратное и рискованное, по возможности их нужно всячески избегать. Если сотрудник-инициатор доработки не смог веско аргументировать и внятно сформулировать (желательно в числовых показателях) пользу от доработки – такие доработки нужно пресекать и не давать им хода. При постановке задач описывать именно бизнес-потребность и бизнес-пользу от выполнения задачи (ожидаемый результат), а не способ её реализации в программе.

Достоинства: данный путь и стиль приведет к тому, что поддержка конфигурации значительно облегчиться, требования к квалификации сотрудников техподдержки уменьшится, стоимость обслуживания снизиться, время реакции техподдержки ускориться, критичные ошибки, приводящие к простоям, исчезнут навсегда; единственно верный подход при обслуживании сложных систем учета; решение на десятилетия, а не на годы.

Недостатки: придется много учиться новому, отказаться от привычного, принимать новые подходы, полагаться на многолетний опыт специалистов.

2.7 Путь 2

Выполнить свертку текущей базы. Свертка базы удаляет все документы из программы и вводит остатки на дату начала учета. Выправить все входящие остатки, отрицательных остатков на начало нового периода быть не должно ни по одному из регистров учета. Остатки по всем регистрам должны совпадать. Пересмотреть и реализовать по-новому учет заказов, резервов, контролей. Пересмотреть все доработки производственного учета. Настроить права доступа - убрать полный доступ у всех пользователей кроме администратора системы. Избавиться от фраз в коде «Если имя пользователя «Мария» тогда можно выполнять действие». Провести ревизию всех внешних отчетов и обработок, удалить не используемые. Сейчас в базе десятки внешних отчетов и обработок, думаю 70 процентов из которых даже не известно, как работают, кто их делал и вообще можно ли их использовать. В тех, с которыми работали мы, видно, что они переделывались несколько раз, т. е. не факт, что они вообще задумывались для той задачи, для которой их сейчас используют. Данный путь позволит начать учет с чистого листа с учетом накопленного опыта.

Достоинства: данный путь приведет к тому, что поддержка конфигурации значительно облегчиться, требования к квалификации сотрудников техподдержки уменьшится, стоимость обслуживания снизиться, время реакции техподдержки ускориться.

Недостатки: множество затрат, но решение все равно временное в виду того что программный продукт морально устарел

2.8 Путь 3

Обслуживание текущей базы требует постоянного внимания и очень глубокого знания процессов компании, данных базы, изучения уже выполненных доработок. База совсем не типовая, получить по ней консультацию на линии консультации у 1С уже невозможно. Нужно по-настоящему работать с базой каждый день, проводить регламентные процедуры, такие как удаление помеченных объектов, восстановление парт. учета, восстановление состояния расчетов с контрагентами, проведение по регистрам НДС, своевременное выявление отрицательных остатков, их корректировка до сдачи квартальной и готовой отчетности. С учетом уже накопленных ошибок учета, ориентировочный срок приведения базы данных в согласованное состояние – 1 год работы по 8 часов в день. 

Обслуживающие организации и фрилансеры имеют ограничения и подходят только определенному сегменту клиентов. За счет наличия в таких компаниях нескольких сотрудников, имеющих большой опыт разноплановых внедрений и обслуживания организаций разных отраслей, такие компании могут хорошо внедрить программы. Качественно обслуживать программы такие компании могут только до определенного уровня модифицированности программы. Если модификация конфигурации носит серьезный характер, то лучшее что может сделать обслуживающая компания, это посоветовать клиенту сотрудника 1С в штат, т. к. дальнейшее обслуживание будет все менее и менее удовлетворительного качества что со временем будет приводить к все большим и большим конфликтам между исполнителями и заказчиком. 

Аренда сотрудника необходимой квалификации на полный день в обслуживающей организации, с учетом налогов и заложенной минимальной прибыли будет обходиться порядка 250-300 тыс. в месяц. Не каждая организация готова пойти на это, т. к. задача организации поддерживать максимально большую клиентскую базу, а не быть придатком нескольких крупных клиентов. Сотрудники тоже не готовы наниматься к одним, а работать на других. По договору абонентского обслуживания с предоплаченным объемом часов обычно выделают не более 40 часов сотрудника в месяц на 1 клиента, остальное время отдается другим клиентам. Т. к. это «размазанные» по месяцу часы сотрудник физически не может изучить такой объем данных конкретного клиента и держать это в голове, а в случае потребности обоснования потраченного времени не имеет возможность обосновать данное изучение данных клиента, ни клиенту, ни своему руководству. 

Чтобы сотрудник знал именно ваш учет на более высоком уровне и работал с базой как со своей он должен четко представлять, что ему с ней работать еще долгое время, что поддерживать её в согласованном состоянии его обязанность на 8 часов в день, и других обязанностей у него нет. За это ему платят гарантированный оклад, который не нужно обосновывать. Если он точечно решит задачу не устранив причину возникновения проблемы, то ему же будет нужно решать её через месяц или через два, объем будет копиться, это не в интересах сотрудника. 

Любая обслуживающая организация или «фрилансер» могут продать вам 40 размазанных часов в месяце, потому что нет способа организации труда в сервисной компании, который бы позволил выдернуть сотрудника на 40 часов подряд без отвлечения на другие задачи, т. к. сотрудник должен окупаться («фрилансер» хочет зарабатывать как штатный сотрудник, поэтому берет себе еще клиентов). Отвлечение значит, что держать в уме больше чем общие принципы ведения учета у конкретного клиента и перечень типовых задач невозможно. Все равно часто приходится решать одни и те же задачи заново, или после первого решения учить клиента делать это самостоятельно, например, если задача учетная и не требует знания программирования. Только штатный сотрудник может действительно глубоко изучить базу данных и через некоторый промежуток времени решать задачи с закрытыми глазами не задумываясь.

Достоинства: за несколько месяцев даже не высококвалифицированный специалист по 1С в штате с 40 часовой рабочей неделей сможет изучить учет в компании, научиться решать типовые проблемы (тушить пожары), которые возникают в ходе работы, вникнуть в ключевые доработки и осуществлять удовлетворительную поддержку программы за фиксированную стоимость. Он всегда под рукой и может реагировать максимально быстро.

Недостатки: с выходом платформы 8.1 не существует больше человека, который знает все программы 1С и все возможности платформы 1С, специалист по УТиВСК может негативно отнестись к переходу на ERP и всячески саботировать данные попытки, находить множество недостатков новой программы и очень аргументированно защищать свою позицию, т. к. переход потребует от него изучения новой не знакомой ему программы, новой ответственности и решения новых задач, которых он еще не решал за тот же оклад; отсутствие мотивации при добавлении обязанностей приводит к раздутию штата (пример компаний, где штат 1С-специалистов всегда разрастается до 5-ти человек); трудность с поиском сотрудника - УТиВСК это 2 конфигурации в одной программе, как такого понятия специалиста по УТиВСК нет, есть специалисты по бухгалтерии, зарплате, торговле, CRM и т. д., причем программисты и специалисты по программам это часто разные люди; сотрудник так же может прийти к выводу что ситуация трудно исправима, тогда это приведет или к текучке кадров на данной ставке или к той же работе по инцидентам, т. к. работа по инцидентам – это простой путь избежать конфликтов и создать видимость бурной деятельности с видимым на первый взгляд результатом.

2.9 Итог

Время реакции компании 1С от регистрации обращения до включения исправления в следующий релиз – около 1 месяца если ошибка не критичная. Критичных ошибок программы, приводящих к простоям действительно мало и их, исправляют гораздо быстрее (в среднем неделю). Ошибок не имеющих способов обхода, чтобы дождаться официального исправления в программах почти нет. Т. е. вполне реально подождать месяц, пользуясь каким-либо обходным вариантом. Информация по ошибкам поступает в виде простого текста на линию консультации, линия консультации выясняет подробности и воспроизводит ошибку на демо-базе и либо сообщает что это не ошибка программы, а ошибка пользователя и предлагает способ исправления. Либо регистрирует ошибку, и дает способ обхода для пользователя. Далее ошибка передается в отдел разработки, где её исправление качественно продумывают. В частности, иногда после исправления ошибки необходимо перепроведение ряда документов только по одному из регистров и только за определенный период, что и делается при обновлении на исправительный релиз автоматически. Так исправления делает только 1С, т. к. у них есть огромные ресурсы для этого. Делать доработки такого уровня сложности не может 1 программист. 

Пожелания на доработку в 1С проходят более длинный путь от пользователя до архитекторов, если 1С решает ввести какой-то новый функционал, то делает это крайне продуманно и учитывает не только пожелания конкретного пользователя, а в целом отрасли. Критичные ошибки 1С, которые могут вести к простоям предприятий и не имеют способов обхода, компания 1С допускает крайне редко, и в этом случае либо отзывает релиз, пока на него еще не успели перейти массы, или выпускает исправительный релиз в течение нескольких ближайших дней. Только такой метод может гарантировать качественную разработку, и все равно даже они допускают ошибки. 

Исправления «в течение часа» - это утопия, они не могут быть продуманы в достаточной степени, и всегда ведут к последствиям. Такие исправления допускается выполнять только на короткий срок, пока не выйдет официально исправление компании 1С. Когда такие исправления накапливаются, начинается то что приводит к текущему состоянию базы. К исправлениям «в течение часа» можно привлекать только специалиста хорошо знакомого с вашим учетом, с возможностями типовой конфигурации и имеющего выход на разработчиков программы и официальную техподдержку 1С. А главное, заинтересованного в сотрудничестве на долгие годы, если человек привлекается на разовые работы в режиме высокой срочности и давления, то и качество соответствующее.

Единственный способ реально сократить расходы на поддержку программного продукта, это оставлять его максимально типовым, задействовать в решении задач саму компанию 1С, чья техподдержка стоит от 15 до 35 тыс. рублей за год за которую вы и так платите. Не обращаться за разовыми работами все время к разным исполнителям. Обслуживающие компании могут качественно поддерживать только конфигурации с ограниченным количеством доработок. Полностью «самописные» программы требуют штата из нескольких человек. Учетные задачи должны решаться консультантами или методистами, а не программистами. Программисты работают по задачам и не вдаются в детали. Проще говоря, они делают то что им говорят и не отвечают за данные базы, только за алгоритмы, качество которых вы не сможете оценить. В обязанности программиста не входит знать типовую конфигурацию и её возможности. Им нужно качественно поставить задачу, для этого нужно либо сделать это самостоятельно, детально изучив типовую программу и возможности платформы 1С, либо воспользоваться услугами проверенного консультанта, который имеет соответствующее портфолио и осуществляет реальную поддержку действующих организаций в течение нескольких лет, т. к. качество баз данных определяется в первую очередь сроком их эксплуатации. Глобальные ошибки проявляются только через годы и сокращают срок эксплуатации базы и качество работы с ней. 

Изначально у меня были опасения после того как я увидел степень доработок, и поскольку я знаю как они делаются были опасения по поводу их качества. Но нужно же всегда надеяться на лучшее! Мы на стороне клиента, и заинтересованы чтобы у клиента все было сделано качественно и работало как часы. Мы не заинтересованы в заработке на постоянных авралах. В связи с тем, что в данной базе УТиВСК слишком большой объем накопленных ошибок как в данных, так и в доработках, срочных задач слишком много, весь бюджет уходит на них, на текущий момент наша компания готова продолжить сотрудничество в рамках бюджета, работая по инцидентам. Исправлять глобальные ошибки в рамках бюджета невозможно. Включить вас в наш цикл ежемесячного обновления программ клиентов мы не рискуем, т. к. ошибки после обновления могу приводить к большому количеству инцидентов, любое обновление — это мини-проект. Работая по инцидентам, мы обеспечиваем решение точечных задач, без гарантии что такая же задача не возникнет в будущем. Если задача возникнет она будет расцениваться как новая задача. Таким образом задачи действительно можно решать «в течение часа» и укладываться в бюджет. В общем то так с вами и работали предыдущие специалисты, потому что как я уже говорил, глобально решить задачу быстро нельзя, быстро можно только создать «видимость» решения.

2.10 P. S.

Вообще эта ситуация не только у вас, многие компании «подсели на иглу» не жизненно необходимых доработок (жизненно важные задачи обычно все решены в типовых программах или решаются двумя-тремя собственными доработками, которые не затрагивают штатную структуру программы), и им ни один менеджер по продажам (или программист который продает сам себя) не может сказать, что со временем это будет слишком дорого обходиться и «видимое удобство», которое дают ряд доработок в конечном счете не приносит большей производительности труда и сокращения расходов, а наоборот разбор ошибок отнимает всё время, фатальные доработки или ошибки учета приводят к необходимости «перевнедрения» программы. Чем мы часто и занимаемся. Внедряем ту же самую программу, в которой люди уже работали, заново, ибо «специалистов по 1С» стало много, людей, которые просто решают задачи – много, а тех, кто знает, как правильно, тех кто может сказать «нет, это делать не нужно, если вы не хотите проблем в будущем, правильней будет сделать по-другому» маловато. 

Работа с программистом на прямую так же губительна, т. к. программист не зарабатывает на продаже программы, он не предлагает такого варианта, даже не потому что он плохой, а потому что программист загружен на 200 процентов, если он хороший. И в то время вариант с переходом с УТиВСК на УПП (Управление производственным предприятием), например, когда началось производство был бы самым логичным, правильным и дешевым. Но программисту это просто либо не пришло в голову, либо он понял, что это увеличит его загрузку с 200 процентов до 400 что ему не нужно ни за какие деньги, либо он просто решил возомнить себя архитектором и придумать функционал лучше, чем 200 человек в компании 1С с многомиллиардным бюджетом и сроками (есть такие фанаты своего дела). Еще вариант, что ему сказали доработать производство в УТиВСК и он это сделал, потому что кто он такой чтобы задавать вопрос «зачем»? Люди бывают робкого десятка. Хотя на его бы месте я бы просто слизал все с УПП, нежели «изобретать велосипед» как это сделано сейчас. Это был бы хоть на сколько-то системный подход. Хотя по деньгам слизывать или купить УПП, когда она еще продавалась за 150 тыс. дешевле было бы купить, честно. Достаточно просуммировать все затраты на обслуживание этого монстра, чтобы понять, что цена программы – это обычно со временем меньше процента получается. 

Мы привыкли играть роль «героев-победителей», которые приходят, наводят порядок, успешно сотрудничают дальше. Но тут мы получается невольно те, кто забивает последние гвозди в гроб УТиВСК т. к. привести программу в порядок в текущих условиях не получиться. В итоге мы окажемся «виноватыми», т. к. всегда виноват тот, кто последний обслуживает базу, так уж сложилось - каждый следующий прораб винит другого в его некомпетентности. Мы бы хотели этого избежать, поэтому пишем это заключение, дабы донести информацию, чтобы вы могли заранее подготовиться и принять какие-то решения, спланировать дальнейшие действия. Собрать из этой комбинации УТиВСК + 8 баз бухгалтерии + 8 баз зарплаты хоть какие-то достоверные отчеты – крайне сложно и требует сверх затрат, я бы никому такого не пожелал. Обычно мы и есть те, кто спасает ситуацию и предлагает правильное решение, когда ситуация достигла финала, но сейчас она еще его не достигла. У меня достаточно опыта чтобы уже делать выводы, поэтому мы в таком деликатном положении, которое хотели бы смягчить. 

Мы можем поддерживать УТиВСК в функционирующем состоянии определенное время, которое зависит не от нас, но уже без глобальных каких-то изменений и доработок. Если выпустят закон, который потребует серьезных изменений, или деятельность компании измениться на какой-то процент, большинство просто обновится на новую версию и все получит считай даром (см. цены на обновления 1С), тут же у нас каждый минимальный шаг влево, вправо грозит либо сверх-затратами, либо втрое сверх-затратами размазанными по времени, потому что сразу все ошибки не всплывут. Мы на вашей стороне, если будет нужно содействие в любых вопросах, мы его обеспечим.

3 Внедрение ERP

3.1 Описание

На совместном совещании при участии заинтересованных специалистов заказчика (учредителей, экономиста и фин. директора) было принято решение о внедрении ERP.

После анализа данных в текущих программах было принято решение ничего не переносить в новую систему. Первая причина. Справочник номенклатура содержал множество дублей не только по наименованию, но и логических «Банка стеклянная» , «Стеклянная банка», что приводило к тому что все равно после переноса данных пришлось бы полностью проверять весь справочник. Справочник контрагенты так же содержал многократные дубли без указания ИНН и адресов, что делало затруднительным или почти не реальным идентификацию контрагента. Проще говоря, ничего «переносить» автоматом из старой системы в новую было не разумно. Вторая причина отказа от переноса — это иная структура программы ERP. В старой программе справочник номенклатура представлял собой простую таблицу разношерстных наименований продуктов и сырья с ценами. В новой системе номенклатура – это мощный инструмент классификации всех входящих и исходящих товаров и услуг. Каждая номенклатура имеет до 10 свойств, по которым возможна фильтрация при подборе в заказы и отчеты. Эти свойства есть в жизни, но ни в одну в программу даже в Excel они не заведены. Справочник контрагенты в старых программах представлен единым списком наименований и ИНН. В новой системе это 2 справочника отражающих управленческую и регламентированную структуру клиентов и поставщиков. Раз нельзя перенести справочники, то об остатках и оборотах не стоит и думать. На самом деле различий еще миллион, в подробности вдаваться не буду. Ключевое – отказ от «переноса» данных полностью.

Еще один принципиальный момент был достигнут на переговорах – любые доработки на этапе внедрения мы делаем только в том случае, если работа без них настолько критична, что предприятие просто встанет колом без них. Позже опишу ошеломляющее открытие, но смысл такой что ничего колом не становиться вообще без доработок, просто некоторым сотрудникам клиента немного неудобно выполнять некоторые операции, но если их поместить в вакуум – делай работу как хочешь, но центральную систему предприятия (1С) изменять запрещено, то сразу способы решения любой задачи находятся.

Для чего такое было сделано. Мы понимаем, что любая система не идеальна, но если на этапе внедрения погрязнуть в этих мелочах, то систему можно не внедрить никогда. Потом в процессе обслуживания мы уже начали реализовывать самые необходимые вещи (из тех без которых можно жить, но «трудновато») и это были точечные доработки не влияющие на поведение системы в целом никак. Т. е. если мы их разом уберем обратно, ничего колом не встанет.

Общая стратегия была выбрана следующая:

3.2 Этап 1. Развертывание

Установка системы на сервер клиента. ERP очень тяжелая и прожорливая система, поэтому к оптимизации ресурсов нужно отнестись серьезно. Система была развернута с соблюдением всех правил, описанных компанией 1С. Таких правил и рекомендаций очень много, но при внедрении более «легких» программ никто им не следует, но с ERP мы решили делать все, как говориться «по науке». Поэтому SQL базы, резервное копирование и регламентные процедуры для них, базы 1С, настройка кластера серверов 1С – все было выполнено под нашим чутким руководством и несколько раз перепроверено. Это предотвратило ряд проблем, с которыми все сталкиваются уже в процессе работы. У нас процесс работы не заканчивался январем (месяцем начала промышленной эксплуатации) и сопровождение системы мы хотели осуществлять долгие годы, находясь при этом в добрых отношениях с руководством компании, поэтому количество внештатных ситуаций хотели сократить до минимума. Это дало свои плоды и тех стандартных ошибок, которые следуют за не грамотной установкой системы мы избежали.

Было создано 4 базы данных ERP. Продуктивная база, в которой непосредственно ведется работа, тестовая база на которой мы и клиент тестируем различные учетные ситуации и доработки, база для разработчиков (которых в общем то не понадобилось), демонстрационная база с тестовыми данными в которой в общем то можно было поиграться всем желающим. Под каждую выделено по 200 гб места на жестком диске.

На выходе: 4 развернутые базы ERP полностью готовые к любым нагрузкам.

3.4 Этап 2. Базовая настройка рабочей базы

После развертывания. Даже когда мы не знаем ничего о конкретном клиенте мы знаем, что ему может понадобиться в будущем и не будет лишним. Тут о клиенте было собрано максимум информации, поэтому в рамках базовой настройки мы заполнили почти все необходимые данные и проверили их корректность.

Все настройки были скопированы в 4 базы клиента.

На выходе: 4 развернутые базы ERP полностью готовые к началу ведения любого учета.

3.4 Этап 3. Моделирование

1. Произвести моделирование будущего учета в новой программе (наши специалисты);

2. Продемонстрировать модель ключевым сотрудникам заказчика для выявления недостатков модели (совместно с заказчиком)

3. Внести исправления в модель (наши специалисты)

Далее по кругу до достижения модели которая удовлетворяет требованиям на 99 процентов.

В процессе моделирования мы поняли что нуждаемся в ERP 2.5 (активно развивающейся версии продукта, а не стабильной на тот момент ERP 2.4)

На выходе: готовая модель учета по которой с нового года компания начнет работать и рекомендации к наполнению базовых справочников; приблизительный список возможных доработок.

3.5 Этап 4. Нормативно-справочная информация (далее НСИ)

НСИ это основа ERP системы. Ошибки в НСИ потом «аукаются» очень серьезно, потому ей нужно уделить времени столько сколько нужно. ERP предоставляет избыточную классификацию всего и вся по видам и свойствам, но у многих компаний нет такой детальной классификации, поэтому приходиться ее выдумывать, обсуждать, советоваться. Работать над внедрением должны все отделы клиента.

Приняты решения:

1. Основываясь на модели разработать новый справочник Номенклатура с нуля. Наименование номенклатуры не должны редактироваться пользователем вручную, а автоматически заполняться по свойствам номенклатуры. Свойства номенклатуры так же разрабатываются в процессе.

2. Справочник Контрагенты и Партнеры будут внесены вручную, при этом будут внесены только актуальные контрагенты, с которыми за последние 3 года были обороты.

1. Остатки номенклатуры по сериям будут внесены вручную с префиксом «Р» (ручная), новые серии будут генерироваться автоматически.

2. Остатки взаиморасчетов будут внесены общими суммами, а уже в процессе учета будут разноситься по объектам расчетов.

3. Список статей доходов и расходов будет проработан совместно

4. Прочие справочники будут заполнены нами по опыту и откорректированы совместно с клиентом.

3.6 Этап 5. Консультационная помощь перед вводом в эксплуатацию и написание инструкций

При заполнении всех данных пользователям требовались консультации по многим вопросам. Схема взаимодействия была следующая: 

1. Пользователь отписывался что он ввел свою часть данных; мы подключались и проверяли заполнение;

2. Мы давали рекомендации по корректировке данных

3. Данные которые были одинаковы для большого количества элементов мы брали на себя разрабатывая разовые обработки по их автоматическому заполнению

В процессе выявились некоторые моменты, о которых мы не говорили на предыдущих встречах. Например, мы поняли что клиент хочет не просто запустить бухгалтерский и управленческий учет, он хочет пользоваться всем функционалом который предоставляет ERP – планирование, бюджетирование, казначейство, логистика, служба качества и много другое. Т. е. масштаб проекта увеличился в несколько раз. Пришлось снова поговорить о деньгах, потому что запуск каждого из этих блоков в некоторых случаях можно рассматривать как отдельный проект.

3.7 Этап 6. Написание индивидуальных инструкций

Т. к. программа хорошо документирована, многих инструкций удалось избежать, тем самым сократив бюджет. Инструкции были описаны только для тех пользователей, которые занимаются рутинной ежедневной работой и вводят большое количество документов в систему ежедневно. Под инструкции попали пользователи отдела продаж, склад и логистика, т. к. ошибки в данных контурах приводят к обработке большого количества данных для исправления.

3.8 Этап 8. Обучение пользователей

Обучение было проведено до нового года по подразделениям. Т. к. отдел бухгалтерии должен владеть всеми участками учета для них еще раз была продемонстрировано подготовленная ранее модель.

3.9 Этап 9. Запуск системы в опытную эксплуатацию

Самый короткий этап, длился с 8 утра до 15 дня 9 января 2020. После того как пользователи не поняли, что вводить в старую программу документы можно только в тех редких случаях, когда что-то не получается в ERP, а потом в ERP их все равно нужно будет перебить. В 15:00 фин. директор сказал «все, отключаем старую программу». Мы дали сигнал системному администратору чтобы он немедля удалил базу из кластера, сохранив только SQL копию. Все. И так начался этап промышленной эксплуатации. Этот опыт я никогда не забуду.

3.10 Этап 10. Запуск системы в промышленную эксплуатацию

Поскольку все было многократно отмоделировано, все на удивление все прошло довольно гладко, учитывая сроки (у нас не было 12 месяцев на тесты как положено, только 5 месяцев). Только январь месяц был немного сумбурный, работа в праздники, ночная работа, работа в каждые выходные, чтобы поправить за всеми недочеты. В итоге к середине февраля январь был полностью откорректирован, за всеми ошибки исправлены, шок и стресс стали сходить на спад, и мы начали заниматься «удобствами». В первую очередь шли «удобства», которые позволяли сэкономить день работы ключевого пользователя клиента, т. е. по-настоящему важные удобства, которые мы начали дорабатывать. Только к концу марта все более-менее вошло в штатный режим и все серьезные неудобства были устранены, поэтому у всех появилось время посмотреть, что же нам система выдает. А работает она довольно хорошо, месяцы закрываются, аналитика немного не та, но это правиться за 10 минут и еще 30 минут пере закрытие квартала. 

Многие вещи пришлось быстро переделывать в процессе. Некоторые сотрудники оказалось не знали принципов нашего подхода, поэтому хотели, чтобы мы что-то там доработали чтобы, было «так как в старой программе». Этого удалось избежать благодаря готовности до конца отстаивать свою правоту, уверенности в что в ERP все уже предусмотрено и ключевым сотрудникам заказчика, которые так же до конца готовы были рубится за правое дело вплоть до криков.

4. Поддержка ERP после внедрения

Поддержка началась сразу с момента начала опытной эксплуатации. Все задачи шли через одно контактное лицо, что дало возможность одному человеку создать полную картину проблем и недочетов для определения приоритетов исполнения задач. Поддержка – это процесс бесконечный и длиться он до сих пор. Задача поддержки – не давать системе скатываться в хаос и поддерживать качество учета на достойном уровне. Поддержка ERP отличается от более простых систем тем, что в ней клиент обращается не к программисту, а к консультанту-методисту по ERP, задача которого вначале предложить вариант решения проблемы «штатными» средствами без выполнения каких-либо работ программистом. Если такого решения не существует, сформулировать задачу для программиста, принять ее исполнение и произвести демонстрацию клиенту.

5. Результат

Что получила компания?

1. Точный учет, в системе которому действительно можно доверять. Все показатели выверены и рассчитаны корректно, система сама контролирует корректность данных и просто не даст выполнить операции неправильно, это сразу всплывает при закрытии месяца и в финальных отчетах. Высокое качество и детализацию данных программы.

2. Корректные данные по клиентам/поставщикам. В базе запрещена регистрация партнеров без указания ИНН, юр. адреса, телефона и электронной почты. Это привело к созданию новых должностных инструкций, которые были нацелены на выявление максимальной информации по клиенту/поставщику до внесения его в базу данных.

3. Гибкую возможность анализа клиентской базы по регионам, типам клиентов (розничный покупатель, дистрибьютер, дилер) и управление маркетинговой политикой по каждому сегменту.

4. Реальные остатки на сладах по сериям и срокам годности, сокращение количества «виртуальных» складов – теперь все склады в системе соответствуют реальным физическим помещениям и мат. ответственным.

5. Управление собственной службой доставки, расчет веса отправляемых заказов для подбора оптимального транспорта.

6. Мощную аргументацию перед налоговыми и прочими проверками. Все данные настолько детально отражены в базе, что можно дать ответ на любой вопрос любых проверяющих органов.

7. Консолидированная отчетность по всем юр. лицам в одном окне.

8. Сокращение затрат на персонал, который оказался избыточен. Операции, которые раньше выполняли N человек смогли выполнять M человек.

9. Огромные перспективы для открытия новых видов деятельности. В старой системе было просто невозможно перейти на ЭДО с контрагентами, потому что для этого ее нужно было бы обновлять, а это было невозможно из-за слишком серьезных доработок. Невозможно было начать вести учет переработки давальческого сырья, как и передавать в переработку. И многое другое в старой системе было бы целым проектом, в ERP это решается установкой одной галки.

10. Новые каналы взаимодействия с клиентами. Тот же ЭДО, бизнес-сеть, возможность оформлять розничные продажи через онлайн-кассы.

11. Все новые возможности платформы 8.3, такие как внутренний чат в программе, интеграция с Telegram и ВКонтакте и многие другие.

12. Перспективы интеграции с сайтами компании и сокращения расходов на контенщиков, заполняющих сайт.

13. Сотрудники получили дополнительное время чтобы заниматься своей работой, вместо того чтобы «бороться» с программой, копируя из нее данные в Excel и корректируя их для отчетности.

14. Возможность быстрого ввода новых сотрудников в работу с минимальным обучением

15. Руководство смогло получать оперативные финансовые показатели из монитора показателей ERP, не вдаваясь в подробности.

От внедрения все получили колоссальный опыт. Работа в новой самой современной системе – это только малая часть. Основной опыт - заранее сколько не моделируй столкнешься с проблемами, которых не предугадали. К этому надо относиться спокойно – дело житейское. ERP внедряется без программиста и доработок вообще на предприятиях которые не занимаются «уникальной» деятельностью.

Конфликты в процессе внедрения – тоже норма, но на стороне клиента должен быть человек, а лучше несколько людей, которые готовы биться за успешность проекта и имеет на это право.

6. Благодарности

Всем сотрудникам компании, которые справились с повышенной нагрузкой и переработками в течение первых трех месяцев работы в новой системе.

Особые благодарности хотелось бы выразить фин. директору и экономисту компании, которые больше всех были заинтересованы во внедрении системы и воспользовались всеми возможными рычагами, чтобы пресечь любые попытки саботажа. Без их волевых решений, какими мы не были хорошими специалистами, мы бы не смогли внедрить систему.