Корпорация ПАРУС

Сделай сам

Елена НЕКРАСОВА, CIO № 9, Сентябрь 2004 г.

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

Лабинский маслоэкстракционный завод специализируется на переработке семян подсолнечника и по объемам производства масложировой продукции занимает одно из ведущих мест в отрасли. Ежегодно предприятие производит около 55 тыс. тонн масла подсолнечного, более 200 тонн пищевых растительных фосфолипидов. Суточная переработка маслосемян подсолнечника составляет до 1000 тонн. Завод является градообразующим предприятием и основным плательщиком налогов в городской бюджет. С 2002 года ЗАО «Лабинский МЭЗ» приобрело имущественный комплекс бывшего Лабинского консервного завода. В реконструкцию и ремонт этого комплекса, обновление ассортимента продукции вложены значительные средства. В результате новую жизнь получила ранее широко известная и пользовавшаяся признанием потребителей лабинская консервная продукция.

Причины, по которым руководство и отдел информационного обеспечения предприятия задумались о внедрении новой информационной системы, были такими же, как и у множества других российских предприятий: требовался новый инструмент информационной поддержки бизнеса, поскольку старая система уже не справлялась с возрастающим объемом задач. Эффективная экономическая деятельность подразумевает минимизацию затрат на производство и снижение себестоимости продукции. Без получения достоверной, полной и оперативной информации добиться этого невозможно. Ситуация усугублялась жесткой конкуренцией на рынке сырья. «Сейчас выигрывает тот, у кого низкая себестоимость, высокое качество продукции и возможность по конкурентной цене купить сырье, — говорит генеральный директор Иван Артеменко. — Чтобы предложить конкурентную цену за сырье, мы должны с помощью информационной системы провести многоплановый анализ и сократить резервы себестоимости».

Кто ищет, тот всегда найдет

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

Основные требования к новой системе были ясны: СУБД промышленного класса, возможность работы под управлением Windows и широкая распространенность системы. Система должна отработать достаточно длительный срок, поскольку частая смена систем нерациональна. Другим важным критерием была идеологическая схожесть новой и старой систем.

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

В результате, после тщательного анализа, проведенного всем коллективом ИТ-отдела, «на финишную прямую» вышли две системы отечественных разработчиков. Одна из них устраивала во многом: трехуровневая система с очень хорошей инсталляцией рабочих мест, нетребовательная к качеству линий связи. Но ее минус, перевесивший все плюсы, состоял в том, что она предназначалась для торговых предприятий. Было ясно, что адаптировать ее под задачи собственного предприятия будет очень тяжело. Второй системой, которую рассматривали на предприятии, был «Парус». Вспоминает Михеев: «Парус оказался для нас более приемлемым. С одной стороны, можно использовать стандартные механизмы настройки без изменения кода, с другой стороны, можно изменять код. Предусмотрен гибкий механизм написания отчетов с применением Crystal Reports или табличных приложений (встроенный Excel). Уже в процессе работы мы по достоинству оценили интеграцию системы с Microsoft Office, в частности — с Excel». В ноябре 2002 года Лабинский МЭЗ и "Корпорация ПАРУС" подписали договор о внедрении системы.

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

Своими руками

Рассказывает Игорь Михеев: «Изначально подразумевалось, что нам нужна помощь на этапе внедрения, а сопровождать систему мы будем сами: адаптировать ее к нуждам предприятия лучше нас никто не сумеет. Конечно, система „под ключ“ с полным набором инструкций — это здорово, но, в конечном счете, получить проблемы можно и в этом случае, ведь технологии меняются, и не всегда эти изменения своевременно отражаются в инструкциях. Основными носителями информации являются все-таки люди, обладающие знаниями и практическими навыками по использованию системы». Так что решено было внедрять систему самостоятельно, но в тесном контакте со специалистами разработчика.

Идея поддерживать самостоятельные внедрения появилась у специалистов «Паруса» спонтанно. «Однажды мы проанализировали удачные и неудачные проекты и с удивлением увидели, что наиболее удачны те проекты, которые клиенты проводят самостоятельно, — говорит Владимир Буторин, генеральный директор "Агентства поддержки проектов автоматизации" (АППА), партнера "Корпорации ПАРУС". — Есть клиенты, которые все делают сами с нуля. Но их не так много. Остальным нужен некий толчок, чтобы проект начал движение. В корпорации возникла идея создать специальное подразделение, которое занималось бы поддержкой таких проектов. Мы разработали специальную методику, которая, на наш взгляд, является ключом к мотивации персонала в процессе внедрения». Решено было делать «выездные учебные центры» — тренинги для конкретного клиента для поддержки самостоятельного внедрения системы.

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

Команда проекта

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

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

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

Хроники одного внедрения

Проект уложился в сжатые сроки — гораздо более сжатые, чем у большинства аналогичных проектов. Работы были начаты в декабре 2002 года, а в опытную эксплуатацию система была запущена в июне 2003-го. И уже в июле система вышла на штатный режим работы. «Можно запускать систему за три-четыре месяца, это вполне реальный срок, если правильно организовать команду, — говорит Владимир Буторин. — Обычно подрядчик присылает на предприятие заказчика некоторый ограниченный контингент специалистов — два-три человека. А здесь со стопроцентной загрузкой работают человек шесть-семь! При этом два-три наших специалиста очень плотно курируют проект».

В теории, стандартная технология внедрения достаточно трудоемкая и дорогая — пишется детализированное техзадание, по полной программе проводится макетирование. В реальной жизни получается иначе: частично заказчик проходит эти этапы, а частично сворачивает их. В проекте ЛМЭЗ технология была комбинированной. Стандартные детализированные механизмы использовали только на проблемных участках, что позволяло сэкономить время и ресурсы.

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

Февраль 2003. «Учиться, учиться и учиться»

Первый, двухнедельный, тренинг был посвящен знакомству с системой, возможности увидеть свои производственные процессы через призму ее инструментов. Такие тренинги традиционно проводятся у заказчика — устраивать выездные тренинги для команды из пятнадцати человек сложно и дорого. Тренинг проводится «методом погружения». «Мы создаем атмосферу, в которую люди погружаются, отрешаясь от повседневной текучки», — рассказывает Владимир Буторин. Такая методика была одним из условий договора. Игорь Михеев вспоминает: «Это было сложное время. В кратчайшие сроки был подготовлен учебный класс на пятнадцать рабочих мест со всем необходимым оборудованием, включая интернет-канал для оперативных консультаций со специалистами "Корпорации ПАРУС". Мы отрывали от рабочего процесса на период учебы именно ключевые фигуры, иногда даже в ущерб основному производству. Но все, включая директора, относились с пониманием — цель того стоила».

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

Этому тренингу предшествовал «нулевой цикл» в декабре 2002 года — обучение сотрудников ИТ-отдела. Двух специалистов обучали в Москве на курсах по Oracle (администрирование и начальный курс SQL). Потом проводилось обучение по установке серверной части и рабочих мест системы.

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

Март-апрель 2003. Задание на дом. Макетирование

Между тренингами всегда существует промежуток времени, чтобы полученные знания можно было применить на практике. Для этого консультанты дают «задания на дом», свои для каждого проекта. Внедренцы ЛМЭЗ получили задание по макетированию системы.

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

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

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

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

Май 2003. Из кандидатов — в мастера

Когда были смакетированы основные бизнес-процедуры, наступила пора написания отчетов. Начался второй тренинг по обучению ИТ-специалистов программированию в системе, возможностям ее модификации, а также овладению в полном объеме средством Crystal Reports, тесно связанным с системой. «Суть тренинга в том, что после освоения приемов работы со стандартным функционалом у специалистов появляется возможность программировать уникальные задачи предприятия. Ни в коем случае не наоборот — „вы скажите нам, что вам надо, а мы вам под это внедрим систему“. Это тупиковый путь. Сначала осознание, и только потом — действие», — предупреждает Владимир Буторин.

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

Май-июнь 2003. Содержание старое, форма новая

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

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

Все это время команда внедрения чувствовала надежное плечо АППА. «В промежутках между тренингами заказчику обязательно надо помогать, вплоть до того, что приезжать и писать программы вместе, — говорит Владимир Буторин. — Совет, особенно по вопросам, которые заказчик даже затрудняется сформулировать, бывает очень ценен».

Июнь 2003. Генеральная репетиция

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

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

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

Июль 2003. «Поехали!»

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

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

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

Июль 2004. Год спустя

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

Система помогает принимать более верные управленческие решения, получать необходимые для анализа данные. Мне, как генеральному директору, необходимо было оперативно получать финансовые результаты деятельности завода. Раньше эти данные я видел лишь через месяц после отчетного периода — с внедрением системы этот срок сократился более чем в два раза, я получаю финансовые результаты работы по каждому виду продукции и услуг».

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

С помощью информационной системы решены специфические задачи предприятия:

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

  • ведется учет меняющейся в зависимости от сезона номенклатуры сырья и продукции;
  • отдельно поступает информация о наличии упакованной и этикерованной (т. е. готовой к продаже) продукции, о сорте товара, сроках годности и его наличии на складах;
  • ведется партионный учет продукции, в частности майонеза;
  • весь ассортимент готовой продукции контролируется с учетом не только сорта, но и фасовки.

Это позволяет эффективно управлять реализацией продукции.

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

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

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

Профессиональное мнение

Владимир Буторин, "Корпорация ПАРУС"

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