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

Intelligent Enterprise: Как начинался ваш проект по внедрению ИС завода? Какие мероприятия нужно провести, прежде чем планировать разработку системы?

Кирилл Соловейчик: Без­ус­лов­но, сначала необходимо сформулировать бизнес­задачи, или, другими словами, понять, что именно мы хотим изменить либо оптимизировать с помощью информационных технологий на уровне всего предприятия. А из этих задач уже вытекают требования к функционалу информационной системы. Затем выбирается способ автоматизации, пишется бизнес­план и на его основе (если решено разрабатывать ПО собственными силами) определяется план по разработке и внедрению ИС. В 2005 году в статье «Развитие ИТ на предприятиях в условиях ограниченного бюджета» (см. IE, № 15/2005, с. 15. — Прим. ред.) я подробно обсуждал мотивы и предпосылки для принятия решения о собственной разработке ПО, поэтому сейчас не буду на них подробно останавливаться.

Про себя могу сказать, что с момента начала работы в ОАО «Ленполиграфмаш» я стал проводить комплексный анализ ситуации, начиная от технического состояния цехов и правил документооборота и заканчивая финансовым состоянием и возможностями людей. Я хотел в целом понять, как работает завод и какие главные проблемы стоят перед коллективом и руководством. Нюанс здесь только один: обычно при автоматизации четко разделяют два состояния системы управления — текущее и ожидаемое (или желаемое в будущем). Я в основу разрабатываемой информационной системы сразу закладывал бизнес­процессы для ожидаемого, оптимизированного состояния, к которому и приводил их админист­ративными мерами. Фактически на момент внедрения практическая реальность сходилась с информационной системой воедино.

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

Почему были выбраны именно такие приоритеты? Все согласны, что на машиностроительном предприятии производство — главное, но проекты внедрения тиражной ERP­системы практически никогда не начинаются с его автоматизации…

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

Однако на «Ленполиграф­ма­ше» ситуация была специфическая: в тот момент производство бурно развивалось, и учет буквально трещал по швам. Я боялся совсем потерять контроль. Таким образом, у меня было два выхода: либо создать нормальную информационную систему, либо существенно наращивать штат учетчиков. Мы должны были контролировать огромную номенклатуру деталей на входе в производство, в процессе по цехам и операциям и наконец на выходе. Поэтому проблема стояла очень остро. И я решил совершить инновационный прорыв, создав информационную систему практически с нуля, внедрив её на фоне прежней численности сотрудников и получив при этом недостижимый ранее уровень конт­роля за всеми производственными процессами. Цель была амбициозная, но мы ее достигли.

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

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

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

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

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

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

Как проходило планирование проекта по разработке?

Я уже говорил, что исходя из приоритетов и понимания будущих процессов мы строили планы разработки и внедрения. Причем, на мой взгляд, на раннем этапе не всегда имеет смысл детально прописывать эти планы. Какие­то моменты я просто держал в голове, тут ничего особо сложного нет. Ведь существует несколько уровней планирования. На самом верхнем укрупненно определяется функционал и последовательность его разработки и внедрения — например, сначала производство, потом конструкторско­технологическая разработка.

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

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

То есть вы говорите о таком эволюционном развитии системы. Насколько детальное в этом случае должно быть технические задание? Ведь важно правильно всё спланировать, чтобы потом не переделывать…

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

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

Здесь необходимо еще раз вернуться к ситуации на заводе. Я использовал все способы, чтобы ускорить разработку. Более того, многие вещи нам приходилось делать параллельно, а иногда и против традиционного потока формирования информации. Скажем, какие­то новые изделия уже производятся, а конструкторско­технологический модуль, который отвечает за их ведение, еще не запущен, и вот маршрутные карты вводились оперативниками прямо на производстве, а затем по ним была сформирована начальная версия спецификации изделий. И здесь было важно объединить эти работы и оперативно управлять ими. Конструкторы только через некоторое время смогли проверить все данные. Ошибок практически не было. Но мы получили возможность анализировать производственные процессы на два месяца раньше. Главное в этой ситуации, чтобы каждый понимал общую задачу и свою роль в её выполнении.

Как при таком эволюционном подходе вы оценивали необходимые ресурсы и время? Каким образом подбирали нужных сотрудников?

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

Мне повезло с коллегами, ведущего программиста я знал давно (мы работали вместе еще до моего прихода на завод) и доверял его оценке. Конечно, хорошо было бы за месяц сделать всех счастливыми, но это ведь нереально. Я ориентировался на его оценку — какие задачи и за какое время он может решать. И предполагая, что это практически идеальная ситуация, так и планировал. Кроме того, я уверен, что никто, кроме него, такие вещи за такое время не реализовывал. Таким образом, учитывая параллельные работы, я совершенно четко знал, что каждый день делаю всё возможное и быстрее идти мы просто не в состоянии.

Проект я начинал с одним программистом, но потом, конечно, пришлось добирать людей. Главное, что я объяснял им бизнес­процессы и требовал их понимания. Иногда я говорил: «Посмотрите, что вы напрограммировали, если вы и дальше так будете делать, заставлю вас на неделю сесть на место сотрудника и работать с той программой, которую вы написали». И это было очень действенно.

Вообще психологические моменты — очень важная составляющая проекта по собственной разработке ИС. Ведь далеко не одно и то же, когда программисты, сидя в своем офисе, пишут тиражное решение для безликого заказчика, и когда они сидят на заводе и работают для людей, с которыми ежедневно видятся. С одной стороны, это, конечно, тяжело. Но с другой стороны, они испытывают особую гордость, ведь то, что они написалибуквально вчера, сегодня уже работает. Насколько важно для молодого программиста такое признание, когда сотни людей уже пользуются его вчерашней разработкой! Более того, их уважают люди, которые гораздо старше по возрасту, они приходят за советом, спрашивают… Это уникальный дополнительный стимул.

Расскажите о внедрении системы. Оно тоже было эволюционным?

Да, во внедрении я придерживался такого же эволюционного подхода. Внедрение осуществлялось постепенно, точнее, мы так планировали. Но как только была установлена первая версия для опытной эксплуатации, начался лавинообразный рост недовольства. Это понятно: даже мне было тяжело разобраться в системе, а людям, которые первый раз увидели компьютер, было в десять раз сложнее. Пользователи не могут понять («ничего не работает, мы ничего не видим, все разрозненно и неудобно»), описание еще не готово, сотрудники не верят в систему, а мы настаиваем на том, чтобы они в ней уже работали. И, разумеется, неизбежны ошибки. Да, конечно, было тестирование силами самих программистов (отдельной тестовой группы не было), была проверка на некоторых пользователях, но ошибки просачивались. В общем — тяжелая со всех точек зрения ситуация. Но это короткий промежуток, главное — его выдержать и не впасть в истерику. Ты как руководитель не имеешь права паниковать. Это чисто психологический эффект: как только ты дал слабину, как только люди понимают, что возврат к старому возможен, — конец проекту. Я сам сидел с начальниками цехов, разбирался, убеждал людей, разъяснял. Тут всем надо недельку поработать с восьми утра до десяти вечера. Дальше становится проще.
Наконец, люди преодолевают первый страх, система как­то начинает работать — и снова психологическая проблема. Как только пользователи на местах понимают, что все работает, они бросают выполнять процедуры, которые делали до создания системы. Это сложный момент — заставить людей дублировать все операции, писать то же самое от руки, чтобы в случае кризиса всегда можно было восстановить данные, чтобы иметь возможность сделать откат, пока система не пройдет полную проверку. Ведь одно дело запустить систему и совсем другое — доверять ее данным. Например, через день работы нельзя предполагать, что введены все приходные ордера, — этого не будет.

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

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

И тут наступает еще один сложный момент: сотрудники начинают выявлять недостатки в том контуре, который уже введен в промышленную эксплуатацию. А чем дальше по времени вы ушли вперед, тем дольше и неприятнее возвращаться и вносить изменения, а ведь ещё стоят задачи по разработке новых модулей. И тут у меня был небольшой провал, который мы, правда, довольно быстро устранили. В какой­то момент я увидел, что мы не развиваемся, остановились и все силы уходят на латание дыр. Причем все изменения в функционирующей системе — это обдуманные предложения, с которыми я согласился и которые утвердил, не оценив, сколько времени эти задачи отберут у программистов. Я понял эту проблему только когда увидел: я ставлю сроки по дальнейшей разработке, а ничего не делается. Здесь необходимо выделять отдельные периоды и в их пределах вводить баланс трудозатрат программистов — скажем, 30% времени на новую разработку и 70% на доработку. Кроме того, следует вводить приоритизацию изменений — что­то первоочередное, а что­то безболезненно можно и через полгода исправить.

Насколько велик риск зависимости от разработчика, особенно талантливого?

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

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

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

Думаю, за такими рассуждениями скрывается то, что ИТ­менеджеры просто боятся взять на себя такой груз ответственности, как собственная разработка. Это ведь колоссальная работа. Но, на мой взгляд, не меньший труд — понять то, что для тебя написали как для руководителя или рядового сотрудника, насколько это соответствует тому заданию, которое ты выставлял. И не просто понять — научиться в этом работать. Кроме того, человек определенного уровня больше склонен к творческой работе. А что может быть более творческим, чем разрабатывать свою систему? Да, это требует большего профессионального уровня. Но это и интересно, и крайне полезно.