Развитие предприятия
|
| Гончарук В.А |
| Продолжение. |
| Построение автоматизированной системы управления | Покупать или разрабатывать? | Если разрабатывать, то как? |
|
Прежде всего оговоримся, что заявленные проблемы, связанные с недостаточной оптимальностью технологий, никуда не уходят. Их все равно придется решать, причем без «правильного» образца. Возможным изменениям в приоритетах и философии бизнеса мы посвятили значительную часть книги, поэтому здесь просто изложим без аргументации логику взаимодействий: Основа – информация о рыночной среде и предприятии. Далее по иерархии: цели > стратегии > структура и технологии. АСУ является стратегическим инструментом управления и обладает приоритетом перед существующими технологиями, но подчиняется основным стратегиям предприятия. С этой точки зрения до разработки следует определиться со стратегическо-целевым комплексом. Может возникнуть искушение решить разработкой АСУ сразу две задачи: приобрести систему себе и получить продукт для продажи на программном рынке. Эти задачи конфликтны: программа «для себя» призвана обслуживать уникальные технологии данного конкретного предприятия, а программа «для других» должна быть стандартизована ради расширения круга возможных покупателей (при этом она теряет уникальность, не решает внутренних задач фирмы и ничем не выделяется на рынке). Попытка «убить двух зайцев» одной разработкой обычно заканчивается изготовлением программного полуфабриката. Но и «правильная» ориентация на единственную цель сама по себе не обеспечит нужного качества. Один из наиболее проблемных вопросов в создании АСУ касается координатора проекта. Традиционно эта роль отводится руководителю группы программистов. Предполагается, что именно он лучше всего способен увязать «простые и понятные» бизнес-процессы с алхимией компьютерных программ. Программисту в любом случае открыта вся информация, закладываемая в систему, назначение его координатором не расширяет круг «слишком осведомленных» людей. Чтобы оценить эффективность традиционного решения, следует рассмотреть логику построения АСУ под руководством программиста. Здесь типичны две альтернативы:
Оба варианта имеют существенные недостатки. В первом случае будут узаконены все перекосы оргструктуры и управления, создан продукт, отвечающий формальным требованиям, но непригодный к использованию. (Например, в одной фирме менеджер сбыта должен был выполнить 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] | |
| [вид для печати] | ||
| © Гончарук В. А. | ||
