Войти в систему
Войти с помощью соц. сетей:
Итак, что мы имели после обследования? Понятный бизнес-процесс производственного учета. И готовую типовую программу, которую можно было протестировать на способность этот производственный учет обеспечить. Но вставал вопрос – как это сделать? Анна Ивановна предложила повторить в программе один учетный месяц. Ввести в нее все сменные рапорта, получить отчеты и убедиться, что баланс по меди сходится.
– А сколько видов продукции у вас на заводе?
– Около 5 000.
– А в плане на месяц?
– Около 200.
– А технологических операций по обработке полуфабрикатов?
– Не знаю… По-разному… От 10 до 100 операций на готовое изделие.
– Представьте, что будет, если мы прямо сейчас решим ввести в программу все операции по плану на месяц. Прежде всего, нам нужно будет создать полный справочник номенклатуры. Ввести спецификации для 200 изделий в плане. И каждую технологическую операцию в маршрутных картах. И это только нормативная база! После этого нужно будет забить в систему тысячи сменных рапортов. И десятки тысяч операций в них. Это несколько месяцев работы – ведь персонал у нас не обучен!
– Так давайте перенесем все из старой системы.
– Вы же говорили, что у вас проблемы с учетом отходов. Я немного разобрался в теме, для нормального учета вам нужны другие спецификации. Если мы просто перенесем то, что есть старой системе, точного учета отходов вы не получите. Всю нормативную базу нам надо создавать заново, по новым шаблонам, с учетом всех ваших требований.
– Да, это проблема.
– Кроме того, представьте, что в непроверенной программе придется что-то дописывать, чтобы удовлетворить ваши требования. При этом окажется, что у части введенной информации придется менять структуру или содержание. А значит, нам потребуется ввести ее повторно. Или мы вынуждены будем отвлекать программистов на написание кода по модификации введенных данных. Процесс затянется еще больше. Но и это еще не все. Каждая типичная ошибка в данных будет повторяться сотни или даже тысячи раз – столько у вас однотипных изделий и операций. И все ошибки придется документировать. А после исправления заново запускать обработки и отчеты. Мы тут можем встрять на месяцы, а в худшем случае – даже на годы. А у нас срок по договору – всего шесть месяцев.
– Так что же делать?
– Давайте возьмем одно простое изделие. Но проделаем на нем все операции, какие только возможны. Примем заказ от покупателя. Закупим материалы. Сформируем задания на производство. Сделаем все полуфабрикаты. Выпустим готовое изделие. Реализуем его. Спишем брак. Оформим возврат от покупателя. Посчитаем себестоимость. И сделаем все отчеты. Если что-то пойдет не так, мы сразу увидим это на небольшой выборке данных. Нам не придется сравнивать «портянки» в 40 страниц по старой и новой программам. Наши отчеты будут на двух страничках максимум. На все такие эксперименты у нас уйдет пару недель, может быть, месяц. Так мы быстро убедимся в работоспособности программы.
– Одно изделие? Ну нет, это слишком мало. Давайте возьмем десяток разных.
– А чем они у вас отличаются?
– Количеством проводов, их расположением и наличием экрана.
– Количество проводов проигнорируем, оно на системе никак не скажется. А вот разная структура изделий может повлиять на результаты. Давайте возьмем два кабеля – самый простой и самый сложный?
– Ладно, давайте попробуем.
– И еще. Давайте сделаем тестовую базу данных и в старой системе. Введем данные контрольного примера и туда тоже. Тогда нам будет с чем сравнить новые отчеты.
– Идея – супер, сделаю отдельную базу данных в старой программе.
И мы сформулировали содержание контрольного примера: «Производство и реализация 10 км изделия РК 50-3-11 и 5 км изделия МКПсЭИКВ 7x2x1,5». А также определили укрупненный набор операций, которые мы должны были проделать в двух программах, чтобы сравнить результаты:
Теперь нам нужно было собрать исходные данные для контрольного примера. Спецификации и технологические карты на изделия и входящие в них полуфабрикаты мы нашли в техническом архиве. Но готовых сменных рапортов (отчетов производства за смену) у нас не было. А их надо было сделать. Мы ввели наши изделия в специальную базу данных для контрольного примера в старой программе и разузловали их. После чего позвали на помощь опытных мастеров. Полученное количество полуфабрикатов они расписали в сменных рапортах так, как будто полуфабрикаты действительно выпустили в цехах завода. Учли последовательность операций, рабочие смены, цеха и бригады. То же самое мы проделали с заказами от клиентов, счетами поставщиков, платежными поручениями и десятком других документов. Заполнили пустые бланки цифрами, которые позволяли смоделировать все операции по закупке материалов, производству и реализации изделий.
После того как входные данные были готовы, мы озаботились получением выходных данных. И снова нам пригодилась старая программа. Мы ввели в нее все наши сменные рапорты и прочие документы. И получили всевозможные отчеты.
В результате у нас сформировался полноценный контрольный пример, включающий в себя содержание – выпуск двух тестовых изделий, входные данные – заполненные бланки документов и выходные данные – полученные на старой программе отчеты.
Пора было приступать к моделированию действий пользователей в новой программе. Список ключевых специалистов был определен в приказе на внедрение. Мы вызывали каждого в ИТ-отдел, сажали рядом и вместе проделывали те операции, которые делал пользователь в старой программе или в Excel. Если что-то не получалось, я записывал замечание в специальной таблице. В этой таблице было описано, кто и какую операцию делает, какой документ вводит. И рядом – как относится к полученному в нашей программе результату. В итоге была собрана информация от 18 различных пользователей о 69 видах операций по вводу данных и получению отчетности.
Вот пример одной такой записи:
Мастер 2-го цеха Айдуллин Л.Н.
Снял показания о метраже полуфабрикатов с рабочих центров. Сделал запись в сменном рапорте о фактическом выпуске полуфабриката и отходах. Сделал запись в цеховой предъявительской записке. Сдал полуфабрикаты в цеховую кладовую.
Входные документы – Сменный рапорт, Цеховая предъявительская записка, Ярлык. Бланки №№ 38–102 с 10.06.2008 по 28.06.2008.
Документы в УПП – Отчет производства за смену (ОПЗС) №№ 38–102 с 10.06.2008 по 28.06.2008.
Проблемы:
1) Невозможно указать в ОПЗС, с какого рабочего центра сняли показания о метраже п/ф, – а от рабочего центра зависят расценки;
2) Невозможно указать количество бухт (необходимо для печати «Цеховой предъявительской записки»).
По завершению этой работы у нас получился полный список операций с замечаниями, с которыми надо было что-то делать. К работе по анализу замечаний мы подключили опытного консультанта. Вместе с ним мы заново прошлись по всем операциям, пытаясь решить возникшие проблемы с помощью изменения настроек программы или отчетов. Кое-где нам удалось это сделать. Но таких записей в «Контрольном примере» было немного. В основном, нужно было делать доработки программы. Часть из них были несложными. Например, разработать новую выходную форму или новый отчет, используя имеющиеся данные в программе. А часть требовала постановки задачи – разработки технического задания или технического проекта. В частности, в программе отсутствовала работоспособная система расчета сдельной зарплаты. Такая, к какой привыкли на заводе – с возможностью получения рабочих нарядов по заполненным сменным рапортам. Самый навороченный документ конфигурации – отчет производства за смену – также пришлось дорабатывать. Он оказался слишком сложным для ввода мастерами.
После того, как все функциональные разрывы были выявлены, мы сели за работу с программистами. Перед нами стояла сложная задача – оценить объем будущих доработок. Без технических заданий и технических проектов. В этой работе нам помогли наш опыт и доступные материалы – «контрольный пример», скриншоты старой программы, печатные формы и отчеты, которые надо было получить из новой системы. Все крупные доработки мы оценивали от 40 до 160 часов. В частности, доработка сменных рапортов была оценена в 40 часов, а разработка рабочих нарядов – в 160. В результате мы получили своеобразный бэк-лог, список доработок, которые надо было сделать, с итоговым объемом доработок в часах. После того, как мы сравнили полученный объем с тем, что был предусмотрительно заложен в договор, выяснилось, что объем доработок – в два раза выше первоначального бюджета.
Что же делать? Делать все доработки – получить довольного клиента. Это, конечно, хорошо. Но, вместе с тем, мы получим и убытки. А это уже плохо. Мы поняли, что без совещания с руководителями предприятия не обойтись. В кабинете директора собрались все топ-менеджеры. После того, как проблема была озвучена, мы перешли к детальному обсуждению каждой доработки. Для того чтобы обсуждение было продуктивным, я серьезно подготовился. К каждой доработке я написал мини-паспорт, в котором описал ее содержание на языке, понятном неподготовленному слушателю. А также плюсы и минусы, если ее делать или не делать. В итоге за два часа были приняты две трети доработок, а треть была отклонена с формулировками «делать в Excel, как и делали, справлялись же как-то до этого».
Но все равно мы не укладывались в бюджет этапа. После совещания директор попросил меня немного задержаться.
– Послушай. Я поговорил с Анной Ивановной. Я все понимаю. Доработки эти нужны. И программа без них не взлетит. Но я не свободен в плане бюджета. Чтобы его увеличить, мне придется идти к собственнику. Сейчас не самые лучшие времена с продажей кабеля. Конкуренция. Мне нужно серьезное обоснование, почему бюджет должен так сильно вырасти по сравнению с тем, на который мы заключили договор.
– Тут все просто. Мы с вами действительно заключили договор на конкретную сумму. Но в нем есть пункт про требования к системе. Там говорится, что если значительно меняются количество автоматизируемых рабочих мест или автоматизируемые функции, то цена также может изменяться.
– Да, есть такое. Но что изменилось? У нас не увеличилось количество работников на заводе. Да и автоматизируем мы, по-прежнему, производство.
– Когда мы с вами подписывали договор, мы включили в него несколько приложений. Одно из них – перечень видов рабочих мест. В нем 14 позиций. В контрольный пример у нас попало 18 должностей. Добавились мастера цехов, цеховые кладовщики, специалисты ОТК и экономисты цехов. И я, и Анна Ивановна считаем, что в новой системе мастера смогут самостоятельно формировать ежедневные задания на производство. И вводить выработку в сменные рапорта. Кстати, просите сразу и бюджет на локальную сеть и компьютеры в цехах.
Вот так нам удалось договориться о корректировке бюджета после формирования списка доработок. А могли и не договориться, заказчики бывают разные. Чтобы избежать рисков, теперь мы процедуру пересчета бюджета после контрольного примера закладываем в договоры в обязательном порядке.
Дальше нужно было дорабатывать программы, и тут возник следующий вопрос – нужно ли делать к таким доработкам технические задания или технические проекты? Подумав немного, мы решили сделать технические проекты только к тем доработкам, которые нам были не до конца понятны. И которые требовали доработки структуры данных программы: создания новых справочников или документов. Отчеты же мы решили делать сразу, поскольку у нас было с чем сравнивать результаты – мы получили полный комплект из старой программы. На проектирование доработок и их разработку ушло еще два месяца. Каждую доработку мы сдавали отдельно, подписывая у комиссии со стороны заказчика «Лист тестирования». В комиссию обычно входили представитель бизнеса и ИТ-директор. Но еще до них первую версию программисты сдавали мне. Тут я выступал в роли бизнес-аналитика. Обычно, если я принимал доработку, ее принимал и заказчик. Хотя, конечно, были и нюансы, связанные с недостаточной проработкой задачи. Но все они решались в тесном контакте пользователей с разработчиками.
Все доработки были сделаны и сданы, и мне хотелось побыстрее запустить программу в работу. Но тут Анна Ивановна заняла твердую позицию.
– У тебя сколько программистов работали над доработками?
– В общем случае – трое, кто-то больше, кто-то меньше. И что?
– А то, что мы каждую доработку принимали на копии инфор-мационной базы данных. А что будет, когда мы все это сольем в единую программу? Ты уверен, что она взлетит? И то, что вчера прекрасно работало в базе у Сидорова, не будет стерто в общей базе?
– В этом я уверен. Они все в хранилище сливают после завершения работы. Но вы все равно правы. Только повторный сквозной пример позволит нам убедиться, что система работает в целом правильно, и мы учли все замечания и требования.
И мы снова прогнали сквозной контрольный пример. Конечно, без сбоев и новых замечаний не обошлось. Но так как пример был очень маленький по объему данных, все замечания мы устранили довольно быстро. Пора было запускать систему в работу.
Войти с помощью соц. сетей: