21 глава из книги нашего директора Рустэма Валеева "Как обойтись без опытной эксплуатации, автоматизируя завод

Продолжаем публиковать отдельные главы из книги нашего директора Рустэма Валеева "Франчайзи на грани нервного срыва".

Автор книги прошел большой и долгий путь в сфере информационных технологий. Ему пришлось поработать и программистом, и консультантом, и руководителем проекта, и начальником абонентского отдела. Он побывал с разных сторон баррикад: и заказчиком, и подрядчиком в проектах внедрения ИТ-систем. За 35 лет автоматизации предприятий наш директор попадал во множество забавных и поучительных ситуаций.

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

Глава 21. Как обойтись без опытной эксплуатации, автоматизируя завод

Салават, как всегда, возник ниоткуда.

– Слушай, у меня есть знакомая. Главный бухгалтер завода. У них там совсем древняя программа, какой-то «Интегратор». Вы сможете им 1С поставить?

– Завод, говоришь? Ну, в принципе, ты обратился по адресу. Мы автоматизировали несколько заводов, опыт есть. Правда, там мы внедряли самописные системы. Но можно попробовать и типовое решение. Ты знаешь, что 1С выпустила не только новую платформу, но и программу класса ERP для заводов?

– Ты имеешь в виду, что комплексную[1] переписали под восьмерку[2]?

– Не совсем. Да, бухгалтерия, зарплата и торговля в ней тоже есть. Но еще и управление производством добавили. И казначейство с бюджетированием. Называется «1С:Управление производственным предприятием», коротко – УПП.

– Вот как. Значит, они в комплексную еще и ПУБ[3] добавили. Хитрый ход.

Мы встретились с главным бухгалтером завода, и я ей объяснил, что УПП – продукт новый. И внедрений у нас пока нет. Но у себя мы его внедрили и очень довольны. В УПП есть все, что им нужно: планирование и учет на производстве, управление снабжением и отгрузкой. Благодаря рекомендациям Салавата, обеспечившим необходимый уровень доверия, мы подписали договор. На тот бюджет, что был у завода, не торгуясь. Для партнерского статуса 1С:ЦКП (Центр компетенции по производству) нам нужно было внедрение УПП. А завод был готов рискнуть с партнером, не имеющим опыта внедрения УПП, но в рамках определенного бюджета. Звезды, как говорится, сошлись.

Все было здорово, кроме одного. Мы еще не внедряли типовые решения на заводах. До этого мы внедряли только собственные разработки. С ними все было ясно – нужно провести обследование, спроектировать и разработать систему, обучить пользователей. Перенести справочники и остатки. Провести опытную и промышленную эксплуатацию. Но как внедрять типовую программу? Если пойти по классическому пути – получалось очень дорого и долго. Самое главное – было жалко тратить время на разработку информационной и функциональной модели «как будет». Мы понимали, что «как будет» уже есть на 90 %. Это готовая типовая программа. Оставшиеся 10 % расхождений, конечно же, нужно было спроектировать. Но как именно это сделать, мы не знали. Тогда еще не было готовых технологий внедрения, предлагаемых фирмой «1С», и мы не могли воспользоваться готовой методологией.

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

Я приехал на завод и отправился в ОПО (отдел программного обеспечения). Начальником отдела была Анна Ивановна, очень доброжелательная женщина. Она рассказала мне про старую систему. Партнер вендора уговаривал их перейти на новую версию. Но они выбрали «1С», и очень надеются, что все получится. Мы с ней определили мое рабочее место на заводе, и я приступил.

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

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

Как делали контрольный пример и рассчитывали объем доработок

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

– А сколько видов продукции у вас на заводе?

– Около 5 000.

– А в плане на месяц?

– Около 200.

– А технологических операций по обработке полуфабрикатов?

– Не знаю… По-разному… От 10 до 100 операций на готовое изделие.

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

– Так давайте перенесем все из старой системы.

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

– Да, это проблема.

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

– Так что же делать?

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

– Одно изделие? Ну нет, это слишком мало. Давайте возьмем десяток разных.

– А чем они у вас отличаются?

– Количеством проводов, их расположением и наличием экрана.

– Количество проводов проигнорируем, оно на системе никак не скажется. А вот разная структура изделий может повлиять на результаты. Давайте возьмем два кабеля – самый простой и самый сложный?

– Ладно, давайте попробуем.

– И еще. Давайте сделаем тестовую базу данных и в старой системе. Введем данные контрольного примера и туда тоже. Тогда нам будет с чем сравнить новые отчеты.

– Идея – супер, сделаю отдельную базу данных в старой программе.

И мы сформулировали содержание контрольного примера: «Производство и реализация 10 км изделия РК 50-3-11 и 5 км изделия МКПсЭИКВ 7x2x1,5». А также определили укрупненный набор операций, которые мы должны были проделать в двух программах, чтобы сравнить результаты:

·         Заказ покупателя;

·         Оплата от покупателя;

·         Заказ материалов;

·         Оплата за материалы;

·         Поставка материалов;

·         Передача материалов со склада в производство;

·         Производство полуфабрикатов;

·         Брак в производстве;

·         Выпуск продукции на склад;

·         Отгрузка продукции;

·         Возврат продукции;

·         Подготовка комплекта отчетов по производственному учету;

·         Расчет себестоимости.

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

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

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

Пора было приступать к моделированию действий пользователей в новой программе. Список ключевых специалистов был определен в приказе на внедрение. Мы вызывали каждого в ИТ-отдел, сажали рядом и вместе проделывали те операции, которые делал пользователь в старой программе или в Excel. Если что-то не получалось, я записывал замечание в специальной таблице. В этой таблице было описано, кто и какую операцию делает, какой документ вводит. И рядом – как относится к полученному в нашей программе результату. В итоге была собрана информация от 18 различных пользователей о 69 видах операций по вводу данных и получению отчетности.

Вот пример одной такой записи:

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

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

Что же делать? Делать все доработки – получить довольного клиента. Это, конечно, хорошо. Но, вместе с тем, мы получим и убытки. А это уже плохо. Мы поняли, что без совещания с руководителями предприятия не обойтись. В кабинете директора собрались все топ-менеджеры. После того, как проблема была озвучена, мы перешли к детальному обсуждению каждой доработки. Для того чтобы обсуждение было продуктивным, я серьезно подготовился. К каждой доработке я написал мини-паспорт, в котором описал ее содержание на языке, понятном неподготовленному слушателю. А также плюсы и минусы, если ее делать или не делать. В итоге за два часа были приняты две трети доработок, а треть была отклонена с формулировками «делать в Excel, как и делали, справлялись же как-то до этого».

Но все равно мы не укладывались в бюджет этапа. После совещания директор попросил меня немного задержаться.

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

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

– Да, есть такое. Но что изменилось? У нас не увеличилось количество работников на заводе. Да и автоматизируем мы, по-прежнему, производство.

– Когда мы с вами подписывали договор, мы включили в него несколько приложений. Одно из них – перечень видов рабочих мест. В нем 14 позиций. В контрольный пример у нас попало 18 должностей. Добавились мастера цехов, цеховые кладовщики, специалисты ОТК и экономисты цехов. И я, и Анна Ивановна считаем, что в новой системе мастера смогут самостоятельно формировать ежедневные задания на производство. И вводить выработку в сменные рапорта. Кстати, просите сразу и бюджет на локальную сеть и компьютеры в цехах.

Вот так нам удалось договориться о корректировке бюджета после формирования списка доработок. А могли и не договориться, заказчики бывают разные. Чтобы избежать рисков, теперь мы процедуру пересчета бюджета после контрольного примера закладываем в договоры в обязательном порядке.

Дальше нужно было дорабатывать программы, и тут возник следующий вопрос – нужно ли делать к таким доработкам технические задания или технические проекты? Подумав немного, мы решили сделать технические проекты только к тем доработкам, которые нам были не до конца понятны. И которые требовали доработки структуры данных программы: создания новых справочников или документов. Отчеты же мы решили делать сразу, поскольку у нас было с чем сравнивать результаты – мы получили полный комплект из старой программы. На проектирование доработок и их разработку ушло еще два месяца. Каждую доработку мы сдавали отдельно, подписывая у комиссии со стороны заказчика «Лист тестирования». В комиссию обычно входили представитель бизнеса и ИТ-директор. Но еще до них первую версию программисты сдавали мне. Тут я выступал в роли бизнес-аналитика. Обычно, если я принимал доработку, ее принимал и заказчик. Хотя, конечно, были и нюансы, связанные с недостаточной проработкой задачи. Но все они решались в тесном контакте пользователей с разработчиками.

Все доработки были сделаны и сданы, и мне хотелось побыстрее запустить программу в работу. Но тут Анна Ивановна заняла твердую позицию.

– У тебя сколько программистов работали над доработками?

– В общем случае – трое, кто-то больше, кто-то меньше. И что?

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

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

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

Как обучали сотрудников и готовили нормативную базу производства

Мы опять сели с Анной Ивановной и начали рассуждать. Как обучить пользователей работе в программе? Кто-то уже работал в старой программе, таким нужно было только показать новую программу. А кто-то до этого даже не держал в руках мышку. Таких предстояло обучить на курсах компьютерной грамотности. Но было очевидно, что учить всех и всему – не нужно. Гораздо быстрее и удобнее было бы научить каждого только его функциям. У нас был контрольный пример, и на его основе мы подготовили общую технологическую карту работы в программе. В этой карте 69 основных операций были выстроены в логической последовательности. От настройки системы и ввода справочных данных – до получения отчетности и расчета себестоимости. В инструкцию для должности мы отбирали только те операции, которые выполнялись на этом рабочем месте. В итоге у нас получилось 18 списков операций. На этой стадии я привлек к работе консультанта. Мария села и сама проделала все операции сквозного контрольного примера. В итоге она разработала 18 инструкций, описав в каждой от 3 до 7 операций по работе с программой. Каждая операция была разобрана очень подробно, с описанием цели выполняемой работы, ее последовательности. Мария привела также скриншоты с примерами ввода данных и получения отчетов. Инструкция для мастера цеха получилась на 24 страницах. Но это того стоило! Ведь нам предстояло не только обучить пользователей, но и запустить техподдержку, которой инструкции давали и общую картину работы программы, и полный реестр действий пользователей.

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

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

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

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

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

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

– Вот как? А когда мы ее внедрим?

– Года через два.

– Что? Да у нас договор всего на 9 месяцев. Хочешь претензию?

– Претензию? К кому? Вот у меня статистика за неделю по вводу данных. С такой скоростью ваши технологи введут наиболее ходовые изделия через 18 месяцев.

– А, вот ты о чем. И что ты предлагаешь?

– Предлагаю перевести их полностью на «сделку». И платить им за каждое введенное изделие. Я предварительно с ними поговорил. Очевидно, что они хотели бы заработать в процессе ввода.

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

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

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

Как обошлись без опытной эксплуатации

Настало время переходить к обычному в таких случаях этапу опытной эксплуатации. Как устроен этот этап? Да очень просто. Нужно параллельно проработать один месяц в старой и новой системах. И сравнить результаты. Ну, не совсем параллельно. Реально продолжает работать старая система. В свободное от основной работы время пользователи пытаются вводить данные и в новую систему. Объем работы увеличивается вдвое, а зарплата, как правило, остается прежней. Поэтому, как только возникает малейший стопор во вводе данных, пользователи радостно бросают работу со словами «эта ваша программа не работает». Проблема устраняется, как только о ней становится известно. И, благодаря административному давлению, ввод продолжается. До следующего затыка. Когда, наконец, все данные введены и наступает время сравнения результатов, возникает другое препятствие. Результаты не сходятся. Никогда. Не помню ни одного внедрения, в котором отчеты в старой и новой программах совпали бы на 100 %. Расхождения возникают из-за несовпадения как исходных данных, так и алгоритмов их обработки. Часть данных и кода в новой системе содержат ошибки. Но не всегда. Иногда ошибочными оказываются старые данные или программа. Поэтому требуется детальный анализ. Такой анализ занимает существенное время, несколько часов, иногда дней, из-за большого объема данных за месяц. Сверку приходится повторять итерационно, после каждой серии исправлений кода или данных. Иногда пользователей удается убедить, что 96 % совпадений – это и есть 100 %, если округлять по правилам арифметики. Но только если главный пользователь – не перфекционист. Перфекционист «склюет вам всю печень» в попытке довести новую систему до совершенства. В итоге из-за огромных затрат времени, мелких сбоев и отсутствия мотивации пользователей опытная эксплуатация обычно продолжается не один месяц, как было записано в договоре, а от трех до шести месяцев. Что делает весь проект по внедрению убыточным для подрядчика и крайне утомительным для пользователей заказчика. Именно из-за этого этапа пользователи, как могут, сопротивляются будущим нововведениям. «Что? У нас планируется переход с УПП на ERP? Предупредите меня за 3 месяца. Я должен подыскать себе новое место работы – поспокойнее».

У нас не было шести месяцев на эксперименты. Даже трех не было. Поэтому я снова попросил всех руководителей собраться в кабинете директора.

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

– Интересно… – подала голос главный бухгалтер Гульнара Маратовна. – Мне, конечно, нравится идея «новый год – новая программа». Но что, если эта новая программа будет недостаточно отлаженной и даст нам неверные результаты?

– Почему она будет недостаточно отлаженной? Мы с вами несколько месяцев занимались контрольным примером. Прогнали в нем все основные процессы. Рассчитали себестоимость. Мы можем полагаться на эти результаты. Благодаря небольшому объему данных, мы тщательно все проверили. И, кстати, сверили отчеты со старой программой. Все идет.

– Вот-вот. Небольшой объем данных. Вот что меня смущает. Реальная жизнь куда богаче.

– Согласен. Никто не говорит, что при переходе к реальной работе у нас не возникнут ситуации, в которых нужно будет исправлять программу. Но таких ситуаций будет немного – 1 – 2 % от общего объема операций. Их исправление, конечно, займет некоторое время. Но не остановит работу всей системы. Мы же, со своей стороны, организуем оперативное исправление таких ошибок.

– Насколько оперативное?

– Постараемся исправлять небольшие ошибки в день обращения. Если будет что-то серьезное, это займет пару дней.

– Ну, пусть производство скажет свое слово.

Слово взял директор по производству Марат Равильевич.

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

– Плохо знают? Я не совсем согласен с этим утверждением. Вот, читаю вам то, под чем подписались все будущие пользователи программы.

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

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

– Ну хорошо, допустим. Но я так и не понял, чем опытная эксплуатация так уж плоха для нас, производственников.

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

– Понятно. Ну, это аргумент. Если вы уверены в программе, я готов рискнуть.

– Погодите, – сказала Гульнара Маратовна. – Я правильно понимаю, что старая программа у нас тоже останется? Если что-то пойдет не так, мы же сможем сделать «ноябрь» в ней?

– Это вряд ли, – подключилась к разговору Анна Ивановна. – Я думаю, если оставить пользователям возможность вводить все в старой программе, многие захотят перестраховаться. Ее придется закрыть.

– Как закрыть? А что, если нам понадобятся данные из прошлых периодов?

– Я имела в виду «закрыть частично». Закроем им ввод новых данных, начиная с 1 ноября. Менять старые данные и получать отчетность пользователи смогут. Иначе, если мы так не сделаем, многие не отнесутся к новой программе всерьез. Старая программа тут уже 20 лет и кое-кто не верит, что его можно заменить. А если мы «сожжем мосты», народ поймет, что другого выхода нет. Или они запустят новую программу, или полностью сорвут отчетность.

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

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

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

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

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

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

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

Я встал и посмотрел на Ивана Ивановича. В кабинете было тихо. И тут Иван Иванович заговорил.

– Старую программу возвращать не будем. Сейчас на заводе нет другого человека, кроме Рустэма, который бы хорошо знал новую систему. Значит, у нас просто нет другого выхода, как довериться ему. Идите и делайте все, что он скажет.

Благодаря поддержке директора и принимаемым мерам, постепенно все наладилось. Однако, как я и предполагал, данные ноября были введены полностью только к концу декабря. Данные декабря – к середине января, и то, благодаря работе в новогодние каникулы. А вот данные января вводились уже практически в рабочем режиме. Как главный бухгалтер сдавала отчетность за ноябрь и декабрь, осталось для нас загадкой. Но нас она не трогала, понимая, как тяжело нам приходится «в поле».

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

Как закрывали проект

В феврале, после того, как себестоимость за январь была, наконец, посчитана и выверена, мы решили закрыть проект. Но не тут-то было. У Анны Ивановны скопилось такое большое количество замечаний и пожеланий, что она никак не хотела нас отпускать. Мои доводы «деньги по проекту давно кончились» Анну Ивановну не убеждали. «А ошибки – нет», – отвечала она мне и просила срочно разобраться с очередной проблемой. Например, быстренько организовать учет драгметаллов, о котором забыли на этапе постановки задачи и вспомнили только сейчас.

Я попросил ее собрать все нерешенные «инциденты» инциденты[5] в один список. После чего мы сели и хорошо поработали над сотней замечаний. В итоге весь список был разделен на пять частей:

1) Вопросы, требующие консультаций, в том числе дополнительной настройки программы.

2) Ошибки в программе, которые необходимо устранить.

3) Требования, которые были выявлены на этапе контрольного примера, но не были реализованы. В этот список попали некоторые отчеты, до которых у нас еще не дошли руки.

4) Требования, которые не были озвучены на этапе контрольного примера, но без устранения которых пользователи не могли обойтись

5) Пожелания к программе, которые неплохо бы реализовать, но без которых можно жить.

После чего мы договорились, что составим список окончательных замечаний к программе, в который войдут все пожелания из пунктов 1, 2 и 3. Консультации, ошибки и требования, которые были озвучены на этапе контрольного примера. По пункту 4 мы договорились о том, что отдел ОПО попробует выполнить нужные доработки собственными силами. А если не получится – мы выполним эту работу в рамках договора сопровождения. Про пункт 5 мы не говорили ничего. А что тут говорить? На перфекционизм в реальной жизни никогда не хватает ни сил, ни времени, ни денег.

Полученный список содержал около 30 замечаний. Мы озаглавили его как «Список окончательных замечаний». Установили плановые даты устранения по каждому замечанию. И сделали внизу такую приписку: «Этот список содержит окончательные замечания, после устранения которых система УПП будет принята в промышленную эксплуатацию. Все замечания, которые возникнут с момента составления настоящего списка и которые будут являться ошибками, будут устранены по гарантии. Остальные замечания будут устраняться силами ОПО или силами подрядчика по договору сопровождения».

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

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

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

Всю книгу вы можете скачать на сайте Литрес:

https://www.litres.ru/rustem-valeev/franchayzi-na-grani-nervnogo-sryva-kak-nebolshoy-firme-partn/

Предыдущая глава из серии доступна по ссылке

[1] Комплексная – «1С:Комплексная поставка», набор программ на платформе «1С:Предприятие 7.7», в которую входила конфигурация «Бухгалтерия + Торговля + Склад + Зарплата + Кадры».

[2] «Восьмерка» или «1С:Предприятие 8». Имеется в виду современная платформа 1С, которая пришла на смену платформе «1С:Предприятие 7.7».

[3] ПУБ – Конфигурация «Производство+Услуги+Бухгалтерия». Типовая программа на платформе «1С:Предприятие 7.7», которую часто использовали для производственного учета на заводах.

[4] MES-планирование (от англ. manufacturing execution system, система управления производственными процессами) – здесь: планирование операций на уровне цехов завода.

[5] Инцидент – незапланированное прерывание или снижение качества ИТ-услуги.