Продолжаем публиковать отдельные главы из книги нашего директора Рустэма Валеева "Франчайзи на грани нервного срыва".
Автор книги прошел большой и долгий путь в сфере информационных технологий. Ему пришлось поработать и программистом, и консультантом, и руководителем проекта, и начальником абонентского отдела. Он побывал с разных сторон баррикад: и заказчиком, и подрядчиком в проектах внедрения ИТ-систем. За 35 лет автоматизации предприятий наш директор попадал во множество забавных и поучительных ситуаций.
Благодаря этой книге вы сможете увидеть всю кухню создания, продвижения и внедрения программных продуктов изнутри. И использовать советы автора в своей работе.
Глава 6. Как автоматизировать завод и не уснуть за рулем
Ламповый завод или «Лампочка», как его ласково называли рабочие, находился в промышленной зоне – у черта на рогах на севере города. Мы с женой снимали квартиру в центре. И мне приходилось вставать в 6 утра, чтобы отвезти сына в школу, находившуюся в самом южном районе, и успеть на завод к 8 утра, к началу первой смены. По этой синусоиде я катался изо дня в день около года, как-то даже уснул за рулем и проснулся за 5 сантиметрах от бампера грузовика, тормозящего на светофоре.
«Аванта» – молодая, только что созданная фирма, бывший вычислительный центр Водоканала, отправленный в свободное плавание. Семь человек. Быстренько создать ТОО[1] пришлось после того, как на уровне города было признано, что увлечение муниципальных предприятий малыми предприятиями является «перегибом на местах». После чего директор кооператива «Вода» вызвал меня к себе, рассказал, что отдел сбыта Водоканала возвращается из кооператива снова в Водоканал. А что делать с вычислительным центром, он не знает, так как ставка зама по экономике в Водоканале есть, а ставок для программистов – нет.
Было самое начало 90-х годов. Я считаю это время рассветом
ИТ-отрасли страны, работы было много, заказы шли сами собой, работало сарафанное радио. ТОО наше потихоньку набирало силу, и вот – заключило договор на автоматизацию завода. Наш самый большой договор. На заводе предстояло автоматизировать три службы – бухгалтерию, отдел сбыта и финотдел.
Эти три службы не очень дружили. Руководители служб ругались на оперативках. Давали настолько разную отчетность за месяц, что директор, когда подписывал договор, сжал мою руку, посмотрел мне прямо в глаза и сказал:
– Послушай. Они дают мне разные цифры. Не совпадает ничего. Ни склад, ни отгрузка, ни дебиторка. Каждый считает, что только его цифры правильные. Я не понимаю, что у меня происходит на самом деле. Я не знаю, кому верить. Ты должен с этим что-то сделать!
Причиной того, что происходило на заводе, являлось полное отсутствие интеграции между программами отделов сбыта и финотдела, плюс сильно отстающая по времени отчетность бухгалтерии, получаемая из бумажных журналов-ордеров.
У нас не было готовой типовой программы для этих подразделений. Тогда с типовыми программами было туго. Даже если бы такая программа появилась, мы запросто могли о ней и не узнать. Интернета не было, а давать рекламу в газетах, радио и на телевидении было не по карману молодым ИТ-компаниям. Поэтому программу для завода нам предстояло написать с нуля.
Первое, что мы сделали – провели обследование этих трех отделов. Результаты зарисовали в виде схем, на которых изобразили основные функции отделов и используемые документы. А также нарисовали стрелочками связи между данными и функциями сотрудников. Собрали образцы всех документов. Тогда еще не были так популярны современные средства формализации требований — разработка моделей «как есть» и «как будет» в case-системах и написание пользовательских историй
(use-case). Мы действовали исходя из простого предположения, что раз мы разрабатываем информационную систему, нам нужно знать все о том, кто и какую информацию обрабатывает, и как именно. А рисунки и образцы документов позволяли получить компактное описание системы.
После чего мы занялись проектированием программы. Разработали структуры всех таблиц. При этом исключили дублирование информации. Если финотдел и отдел сбыта использовали для регистрации оплат разные таблицы в разных программах, у нас это была единая табличка для всех служб. За основу мы взяли систему бухгалтерского учета. Идея все построить на операциях и остатках мне очень нравилась, так как принцип двойной записи, применяемый в бухгалтерии, обеспечивал высокую надежность системы.
«Засада» началась, когда мы приступили к программированию. В этих трех отделах на заводе работало человек 50, каждый рассказал о том, что он делает, и нам надо было написать громадную кучу кода. Товарные и железнодорожные накладные, партионный учет на складе, отгрузка посылками и в контейнерах, учет векселей и других ценных бумаг… Система получалась огромной. А программировать на FoxBase – это вам не в 1С объекты создавать! Каждый справочник, документ и отчет надо было писать как уникальный, вручную. Проработав месяц почти каждый день до глубокой ночи, я задумался. Последнее, что меня окончательно убедило, что мы что-то не то делаем, был случай в январскую ночь. Я приехал на завод в 8 утра, а уезжал в 2 ночи. С утра шел снег, и я с трудом нашел свою машину на стоянке возле завода. Откопал ее. Завел мотор и тут же, через 30 метров, застрял на трамвайных путях, которые просто были не видны под снегом! Мне крупно повезло, что пути ночью чистил специальный трамвай-снегоочиститель. Мужик в кабине поржал немного, увидев мою пятерку на рельсах, прицепил трос и вытащил меня на переезд, откуда я смог выкатиться на шоссе.
В тот день я понял, что если все оставить как есть, то никакого здоровья нам не хватит закончить систему. Прошло уже несколько месяцев с начала проекта, деньги кончались вместе с кредитом доверия директора, а нам все еще нечего было показать пользователям.
И тогда я сделал то, что у меня всегда получалось лучше всего – я автоматизировал нашу работу. Создал универсальный интерфейс, универсальный справочник, универсальный документ и универсальный отчет. Все эти вещи управлялись простым заданием параметров – как правило, указанием таблиц, с которыми работали программы, и их реквизитов. Теперь все программирование заключалось в правильной настройке универсальных объектов, все остальное – расположение реквизитов на экранах, их ввод, редактирование и прокрутку, – программа делала сама. И дело пошло куда веселее. Производительность труда выросла в несколько раз! У сотрудников моих начали потихоньку рассасываться круги под глазами, и в них снова зажглась надежда.
Но деньги все же кончились раньше, чем кодирование. Хорошо, что нам к тому времени было, что показать, и директор завода, хоть и с ворчанием, но подписал дополнительное соглашение. Хороший был руководитель, приходил несколько раз к нам вечером после окончания рабочего дня, наблюдал, как мы работаем. Понимал, что деньги тратятся не впустую. Мы потом еще много раз сотрудничали с ним. Как-то он даже приглашал меня на должность начальника АСУ завода. Но я тогда работал в Сотовой связи и отказался.
И вот настал счастливый день запуска системы в промышленную эксплуатацию. Бухгалтерия и финотдел взлетели сразу. Бухгалтерия вообще нарадоваться не могла после бумажных журналов-ордеров. У них сразу же исчезла необходимость «сводить» разные счета. Единственное, что их беспокоило – как поделить оставшиеся обязанности. Неожиданно у бухгалтера Светы, которая вела 60-й счет (взаиморасчеты с поставщиками), почти не стало работы. Материалы по документам приходовали бухгалтера материального стола, а оплаты – бухгалтер, разносивший банковскую выписку. Так как вся необходимая информация вводилась на других участках, учет с поставщиками получался автоматически. Бухгалтеру 60-го счета оставалось только готовить акты сверки. Проблему нагрузки решили, передав Свете учет по какому-то из неавтоматизированных счетов. Потому что переделывать программу так, как она хотела (разбивая приходный документ на два – для нее и для материалистов), мы отказались.
Но с отделом сбыта получился эпический фейл. Выяснилось, что им совсем не подходит разработанный нами «универсальный интерфейс», и они отказываются с ним работать! Потому что в предыдущей программе «все было на одном экране и было удобно, а так нам приходится три экрана открывать, чтобы все увидеть». Что было с ними делать? Мы долго пытались их уговорить, убедить, что дело только в привычке. Что три экрана – это даже удобнее, меньше информации на каждом. Но ничего не помогло. Даже отказ переделывать интерфейс. Начальник отдела отправилась к директору. Так как ее цифры по отгрузке нравились ему больше всего, ее влияние на директора было значительным. И к нам поступило жесткое распоряжение – «сделать все так, как будет удобно отделу сбыта». Аргументы, что в бухгалтерии все то же самое, но людям нравится, не помогли. И мы, чертыхаясь, переписали для отдела весь интерфейс, потратив еще неделю.
Тогда я понял две вещи. Первая: интерфейс и привычки людей – это очень важно. Нужно готовить людей к его изменению, проводить специальное обучение. А вторая: стейкхолдеры[2] бывают разные. Кое-кого можно убедить в своей правоте, а кое-кого придется просто слушать и исполнять. А то акт-то и не подпишут.
Еще несколько месяцев мы прожили в стрессе, собирая днем требования по доработке, а по вечерам внося изменения в код. Но система заработала и дала нужный директору результат. Наконец-то он получил отчетность, в которой все цифры отделов полностью совпали, так как были получены из единой базы данных! Надо было видеть его глаза, полные радости! Такие мгновения наполняют жизнь автоматизатора смыслом, давая энергию для разработки новых систем, облегчающих людям жизнь и освобождающих им время для творчества.
Напоследок я добавлю только, что наша программа «Свет» положила начало созданию ERP-системы «Лампочки», которая проработала на заводе более двух десятков лет и успешно развивалась собственным АСУ завода.
Всю книгу вы можете скачать на сайте Литрес:
https://www.litres.ru/rustem-valeev/franchayzi-na-grani-nervnogo-sryva-kak-nebolshoy-firme-partn/
[1]
ТОО – «Товарищество с ограниченной ответственностью». Устаревшая организационная форма частного предприятия, которую в настоящее время заменяет ООО – «Общество
с ограниченной ответственностью».
[2] Стейкхолдер (англ. stakeholder) –заинтересованная сторона, причастная сторона, участник работ, роль в проекте – лицо или организация, имеющая права, долю, требования или интересы относительно системы или ее свойств, удовлетворяющих их потребностям и ожиданиям (ISO/IEC/IEEE 15288:2015, ISO/IEC 29148:2011:6).