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

Немного о проекте в целом.

Прежде всего, напомним читателям, что речь идет о внедрении 1С:ERP на промышленном предприятии.  В 2015 году, когда мы занялись проектом, на заводе трудилось 5000 человек. В процессе внедрения 1С:ERP завод значительно увеличился, вместе с ним выросли и объемы производства, количество сотрудников достигло 6500. 1С:ERP установили на 1200 рабочих мест, активно ею пользуются 350 человек, однако, в дальнейшем ожидается увеличение количества пользователей до 450.

Завод относится к военно-промышленной отрасли, соответственно, у него своя специфика работы. До данного предприятия у меня были более мелкие проекты, на 1000-1500 сотрудников и 50-150 рабочих мест. Поэтому, внедрение 1С:ERP было уже процессом наработанным, имеющим свою методологию. В данный момент данная процедура на среднем предприятии занимает не более 10 месяцев. Срок зависит только от сложности проекта. Но опять же, все это касалось средних предприятий, на которых не более 2,500 сотрудников. Когда же дело коснулось большого завода с огромным штатом работников, то возникла необходимость пересмотра технологии.

Наша история внедрения.

Но, обо всем по порядку. Когда в 2015 мы занялись заводом, перед нами поставили задачу запустить регламентированный учет. По ходу функционального моделирования руководство Заказчика (с подачи главного бухгалтера) приняло решение о передачи функции ввода первичных документов «на места». Границы проекта были пересмотрены, включив в себя центральные склады, кладовые, цеховую бухгалтерию, управление договорами и БДДС. В связи с возникшими нюансами пришлось отложить создание регламентированного учета до 2017 года. В 2016 году мы внедрили так называемый «первичный» вариант проекта.

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

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

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

Первое, с чем пришлось столкнуться, это объемы данных, а точнее, их недооценка. Допустим, что обычный перенос остатков занимает около 4 суток, а если обнаруживаются ошибки и неточности, то процесс исправления займет еще столько же времени. Поэтому, к данному этапу работ следует подходить с особым вниманием, расписывать его вместе с заказчиком по дням. Мы же нашли выход из ситуации следующим образом. Загрузили справочники и предложили пользователям вводить только первичные данные. Когда загрузка была окончена, потребовалось только провести остатки, все сверить и вывести на оперативный учет. Это привело к тому, что до конца месяца мы не уложились. Для того чтобы свести таки учет, подготовить отчетность потребовалось переносить данные из старой системы вручную, а потом это все скорректировать под каждую методику учета.

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

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

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

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

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

Еще один отдельный вопрос – это система коммуникации пользователей программы. При внедрении каждого модуля следует обязательно сделать настройку входящих сообщений, потому как, обзванивать пользователей при каждом обновлении программы, это нереальная и бесполезная, по сути, задача. Только время потратите, а толком что-либо сделать не успеете. В данной ситуации очень выручает Библиотека Стандартных Систем или БСП.

Другой серьезной проблемой оказалась низкая компетентность самих сотрудников завода. Каждый работник знал только ту часть учетного модуля, с которой имел непосредственный контакт, причем о всей работе модуля он не знал практически ничего. Что же касалось руководителя отдела, то он владел только общими знаниями о работе своих сотрудников. И ни на одном из корпоративных уровней не было специалиста, который знал все досконально. Изначально, мне казалось, что такое происходит только на этом заводе. Но, как выяснилось позже, это глобальная проблема для всех крупных предприятий. А точнее, это их норма действительности, к которой уже все привыкли.

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

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

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

Проведя анализ проекта, мне не удалось выявить способы по уменьшению расхождений между процессами и реальностью. Для более тщательного планирования по каждому отделу с согласованием у руководителей заказчику придется увеличить бюджет в 5-7 раз. А это достаточно сложно, ведь не каждому можно объяснить целесообразность таких затрат.  Были мысли о тестовом использовании системы, и я даже реализовала ее в другом проекте, но значимых результатов это не принесло.

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