Letyshops

Развитие предприятия

Гончарук В.А
Продолжение.
Построение автоматизированной системы управления | Покупать или разрабатывать? | Если разрабатывать, то как?

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

Основа – информация о рыночной среде и предприятии. Далее по иерархии: цели > стратегии > структура и технологии.

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

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

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

Чтобы оценить эффективность традиционного решения, следует рассмотреть логику построения АСУ под руководством программиста. Здесь типичны две альтернативы:

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

Оба варианта имеют существенные недостатки. В первом случае будут узаконены все перекосы оргструктуры и управления, создан продукт, отвечающий формальным требованиям, но непригодный к использованию. (Например, в одной фирме менеджер сбыта должен был выполнить 131 операцию «мышкой», чтобы выписать покупателю счет из 5 позиций. При этом программа отвечала формальным требованиям ТЗ.) Во втором случае будут воспроизведены технологические решения из прежнего опыта программиста, которые не обязательно будут эффективны для данного предприятия.

Начало в выпусках: #149, #150, #151, #152, #153, #154, #155, #156, #157, #158, #159, #160, #161, #162, #163, #164, #166, #167, #168, #169, #170, #171, #172, #173, #174, #175, #176, #177, #178, #179, #180, #181, #182, #183, #184, #185, #186, #187, #188, #189, #190, #191, #192
Продолжение в выпусках: #194, #195, #196, #197, #198, #199, #200, #202, #204, #205, #206, #207, #208, #209, #210, #211, #213, #214
<<предыдущая [1][2][3]
[вид для печати]
© Гончарук В. А.

 

 

Реклама: