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

Так, наше исследование «Практика использования ИТ на российских предприятиях — 2008» показало, что 35% предприятий в области управления производством используют собственные разработки, еще 25% — автоматизацию «подручным» офисным ПО. То есть 60% опрошенных ИТ-директоров тиражное ПО в своей работе не применяют. Такое соотношение понятно и объясняется в основном историческими фактами, что хорошо показывает наше интервью. Однако при этом многие промышленные предприятия сознательно продолжают ориентироваться на собственные разработки. Наше исследование показало, что 65% опрошенных намерены использовать для управления производством комплексные ERP-системы, еще 10% — продукты «лучшие в своем классе», а оставшиеся 25% принципиально ориентируются на собственные разработки. Этих последних уже нельзя отнести на счет исторических причин, тут явно просматривается четкое и осознанное решение.

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

Intelligent Enterprise: Почему для автоматизации предприятия была выбрана именно самостоятельная разработка? Что при этом сыграло решающую роль?

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

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

Какие системы удалось самостоятельно разработать и какие задачи остались не закрытыми?

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

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

Здесь надо сказать, что информационная служба на нашем заводе как была, так, к сожалению, и остается не вполне централизованной. Несколько лет назад делалась попытка объединения, но завершилась она тем, что число ИТ-подразделений сократилось с четырех до трех. Вне центральной информационной службы остаётся информационная служба конструкторских отделов и служба информационной безопасности, а также задачи использования CAD/CAM-систем, программирования ЧПУ и связи. При этом для решения текущих вопросов в составе конечных подразделений имеются системные администраторы.

В качестве иллюстрации появления и развития самописных ИС можно привести пример нашего внутреннего заводского портала. Унаследованная система предусматривала отчеты, выдаваемые сотрудникам. Однако отчеты эти не давали всей необходимой информации, и у пользователей периодически возникали типовые вопросы, требующие разъяснения сотрудников ИТ-службы. Вместо того чтобы каждый раз отвечать на эти вопросы, с появлением веб-технологий мы вынесли на внутренний сайт максимально часто запрашиваемую информацию — а именно материальный состав изделий и межцеховые маршруты их обработки. Это была собственная инициатива службы, поэтому возможность привлечения сторонних разработчиков не рассматривалась, все было сделано нашими собственными ресурсами. Так и продолжается: при возникновении новых вопросов разрабатываются новые веб-страницы.

Сколько при этом разработчиков у вас в штате? От чего зависит оплата труда программистов? Как они мотивируются?

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

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

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

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

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

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

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

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

Как разработчики справляются с изменчивостью требований бизнес-подразделений? Как вы управляете изменениями, в том числе в самой постановке задачи разработчикам?

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

Не боитесь зависимости от кадров при такой ориентации на самостоятельную разработку?

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

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

Если руководство сознательно делает ставку на собственные разработки, может быть, стоит подумать об использовании CMM [Capability Maturity Model] или других моделей зрелости процессов создания ПО?

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