Сетевой журнал: галерея ИТ-проектов

КРОК: нефтяной холдинг модернизирует материально-техническое обеспечение

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

Без централизованного корпоративного справочника товаров специалисты по закупкам постоянно сталкивались с проблемами их дублирования, затягивания сроков исполнения заявок, "замораживания" складских запасов. Кроме того, реализуя намеченную стратегию развития, высшее руководство холдинга поставило перед снабженцами задачу не только годового, но и трехлетнего перспективного планирования закупок. Однако уже при годовом планировании организация закупок требовала от персонала больших усилий. С вводом же трехлетнего плана объем работы увеличивался, а штат сотрудников Торгового дома оставался прежним. Холдинг развивается, строит в разных регионах страны новые крупные объекты, а это тоже прибавляет снабженцам работы.

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

Заявочную компанию на закупки 2005 года руководство холдинга запланировало завершить к концу октября 2004-го и провести ее с использованием уже работающей системы. Это означало, что Торговый дом как заказчик решения должен был уложиться с его внедрением в весьма сжатые сроки. Предстояло за август и сентябрь 2004 года сдать в штатную эксплуатацию функционал системы, обеспечивающий составление заявок, в том числе подготовку всех необходимых для этого данных (ранее копившихся в формате MS Office Excel). По этой причине выбор решения ограничивался классом "небольших" ERP-систем с "быстрым" внедрением.

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

Тендер в июле 2004 года выиграла компания КРОК. Несмотря на то что любая фирма предпочитает работать с уже проверенными партнерами, КРОК сумел выиграть конкурс, не имея до этого никаких деловых отношений с заказчиком. На предпроектных презентациях КРОКу удалось продемонстрировать видение "слабых звеньев" в цепочках бизнес-процессов материально-технического обеспечения заказчика и умение их исключить или упрочить средствами Navision. Интегратор предложил основанные на Navision решения (связанные в том числе и с программными разработками), которыми он уже располагал к тому времени и которые соответствовали выдвинутым требованиям. Накопленный опыт КРОКа закладывал фундамент для сокращения объема проектных работ, сроков их выполнения и одновременно снижал стоимость решения.

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

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

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

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

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

Система Navision рассчитана на работу с "толстым" клиентом в локальных сетях. В рамках же проекта к ней пришлось подключать и удаленные "дочки", не охваченные локальной сетью. Для этого были разработаны две схемы. По одной из них для компаний, не имеющих постоянного канала связи, создается набор файлов в формате MS Office Access, содержащие данные общекорпоративных справочников. На стороне "дочек" был предусмотрен ввод данных в эти файлы и последующий их импорт в систему. В другой схеме использовался терминальный доступ к системе на базе технологии Citrix. Это позволило задействовать в терминальном режиме каналы с низкой пропускной способностью (от 25 кбит/с). Сегодня часть "дочек" работает с системой по терминальному доступу к расположенному в Москве серверу, не испытывая при этом проблем с производительностью. Использование этой технологии незначительно увеличило стоимость проекта: одно рабочее место с подключением Citrix обошлось в 400 долл. Тем не менее для заказчика это оказалось значительно выгоднее, чем внедрение системы со встроенной поддержкой распределенных структур (например, решение на базе Axapta обошлось бы процентов на сорок дороже, не говоря уже об увеличении сроков внедрения).

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

Система обслуживает следующие подразделения холдинга:

  • отдел сводного планирования Торгового дома – пять рабочих мест;
  • поддержка ведения договоров с дочерними организациями в Торговом доме – два рабочих места;
  • обслуживание самостоятельных закупок дочерних предприятий (помимо централизованных) – два рабочих места (в Торговом доме);
  • отдел проведения конкурсных торгов Торгового дома – семь рабочих мест;
  • отдел сопровождения договоров Торгового дома – семь рабочих мест;
  • централизованное планирование закупок – по два рабочих места в каждой дочерней организации.
    При реализации проекта были максимально задействованы стандартные бизнес-процессы Navision. Тем не менее особенности заказчика потребовали программных изменений и доработок решения. Их объем составил около 20% от базисного функционала системы /*см ниже "Структура временных затрат проекта"*/. При проведении программных доработок интегратор всегда должен учитывать, что чем больше в системе содержится уникальных данных (которые дополняют основные справочники, таблицы и т.п.), тем сложнее отслеживать изменения и проводить переход на новые версии продукта. У продвигающей систему Navision компании MBS есть типовые формализованные требования к качеству разработок, выполненных для вертикальных решений. Если изменения в системе оформлены в соответствии с этими требованиями, то они могут получить статус расширений к базовой версии Navision и при необходимости будут поставлены дополнительно. MBS аккумулирует отраслевые расширения, сделанные для Navision, предлагает разработчикам свою помощь в продвижении их продуктов. Сотрудничать с MBS в этом направлении удобно. КРОК пока не оформил собственные разработки для Navision в формате стандартных требований MBS. Но при первой необходимости эта процедура будет проведена без особых усилий – дело здесь за оформлением необходимых документов.

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

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

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

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

    Структура временных затрат проекта
    Для ведения внедренческих проектов КРОКом за основу взята методология Microsoft Business Solutions, которая постоянно совершенствуется на основе собственного опыта интегратора. Кроме того, в компании разработана и используется система учета рабочего времени Incident Tracker, интегрированная с MS Project. Этот инструмент позволяет руководителям проектов оперативно ставить задачи всем участникам работ, контролировать затраченное при этом время и качество выполнения. Данные, полученные с помощью Incident Tracker, позволяют читателям этой статьи оценить структуру временных затрат в рассматриваемом проекте.

    Распределение времени исполнителей в проекте:

  • анализ; формирование функциональных требований –15%;
  • проектирование системы –29%;
  • реализация модификаций – 41%;
  • опытная эксплуатация системы – 15%.

    "Центр ответственности" эксплуатации ИТ-системы
    Существует общая для всех компаний острая кадровая проблема, связанная с назначением на позицию "центра ответственности" специалиста, способного поддерживать информационную систему со стороны бизнеса. Его задача – декомпозировать проблемы бизнес-пользователей в системные и локализовать их. Он играет связующую роль "главного посредника" между системой и бизнесом. Для ИТ-специалиста это хороший вариант сделать карьеру. Но чаще всего эту функцию на себя берут люди из бизнес-подразделений. Если такие «посредники» между бизнесом и системой возникают в нескольких подразделениях, то в компании могут возникнуть проблемы с интеграцией пользовательских замечаний по поводу работы системы, поскольку они адресуются не в единый центр, а к "посредникам" в подразделениях. От "главного посредника" многое зависит, поскольку он наделяется возможностями расставлять приоритеты проблем, и может это делать в зависимости от своего положения в компании, от собственного понимания ситуаций, а не с позиций их критичности для бизнеса в целом. Правильнее, если роль "главного посредника" выполняет руководитель ИТ-службы. Он должен держать все нити в своих руках, "выращивать" в бизнес-подразделениях "локальных посредников", включать их в работу свого подразделения (а в идеале в штат подразделения). Тогда его служба из затратной превращается в неотъемлемую составляющую бизнеса компании. Но заказчиком ИТ-системы, в дальнейшем спонсором проекта, а затем, возможно, и главным бизнес-пользователем всегда должен быть кто-то из высших руководителей компании, в руках кого сосредоточены достаточно мощные административные рычаги.

  • сетевой форум
    поиск
    подписка на журнал
    о сетевом