ПРОЕКТИРОВАНИЕ СИСТЕМЫ
Превращение спецификаций в проект — трудная задача. Требуется определить, как получить перечисленные качества: что сделать, чтобы наделить организацию или ее деятельность этими качествами. Недостаточно, например, определить, что корпорация должна обеспечивать высокое качество жизни своих сотрудников на работе, нужно решить, как реализовать это обязательство. Как спроектировать операции и рабочее место, чтобы улучшить качество производственной жизни? Насколько контролировать, какую работу выполняют сотрудники и когда? Какие возможности продвижения обеспечить для них и как? В какой степени допускать их к принятию касающихся их решений? В какой мере вознаграждать их за выгоды, принесенные корпорации улучшением работы, за которую они отвечают?
В качестве примера превращения спецификации в проект рассмотрим, каким образом была реализована спецификация об исключении ошибочных вызовов из телефонной системы. Есть два вида ошибочных вызовов: когда номер известен точно, но набирается неправильно и когда неправильно запомнил номер и правильно или неправильно его набифаешь. Рассмотрим эти виды ошибок раздельно.
Первый — неправильный набор правильного номера - можно исключить следующим образом. Трубка не поднимается, пока не набран номер. Номер набирается на кнопочном пульте телефона. Набранный номер появляется на экране, напоминающем экран калькулятора. Вызывающий видит номер и проверяет его: если он правильный — снимает трубку, и номер автоматически вводится в систему, если нет — нажимает кнопку сброса и набирает заново. Такой путь практически исключает ошибочные вызовы первого вида.
Ошибочные вызовы второго вида — правильный или неправильный ввод неправильного номера — можно практически устранить, если после набора номера, как указано выше, но раньше, чем отправить вызов в систему, вызывающий набирает фамилию абонента. Тогда номер вводится в систему вместе с фамилией, и система сначала проверяет соответствие номера и фамилии. В случае несоответствия загорается индикаторная лампочка на аппарате и система не принимает вызов.
Оба эти решениятехнически осуществимы.
Проектирование — кумулятивный процесс. Начинается он очень широкими мазками. Поэтому первый вариант представляет собой грубый набросок. Затем постепенно добавляются детали и вносятся уточнения. Процесс продолжается до тех пор, пока не будет получен детальный проект, позволяющий выполнить его так, как задумано разработчиками. Например, спецификация об исключении ошибочных звонков была трансформирована в набросок проекта модифицированного телефона, описанный выше. Однако чтобы сконструировать такой аппарат, требуется больше детален.
Детальный проект организации — вытекающий из спецификации о том, что она должна быть гибкой, — описан в гл. 6. Другой проект — соответствующий спецификации о том, что каждый управляющий должен располагать управляющей системой, дающей ему возможность быстро обучаться и приспособляться, — описан в гл. 7.
Когда получены элементы проекта, их следует проверить на техническую осуществимость. Если их осуществимость не очевидна для разработчиков, следует проконсультироваться со специалистами. Например, в случае с ошибочными телефонными звонками так и сделали, и специалисты нашли, что это осуществимо. Они также определили, что реализация не потребует больших средств; напомним, однако, что вопрос об издержках к идеализированному проекту не относится.
Когда установлена техническая осуществимость элементов проекта, их нужно объединить во всеобъемлющую связную картину (сценарий) целого.
Первый полный вариант идеализированного сценария необходимо всесторонне проанализировать. В частности, следует тщательно проверить его на функциональную жизнеспособность.
Проекты, связанные и не связанные ограничениями
Является ли корпорация независимой или дочерней, проект ее ограничен характером той системы, частью которой она является. Очевидно, например, что деятельность корпорации ограничена по меньшей мере одним правительством, а дочерней компании — ее родительской организацией.
По этой причине желательно разрабатывать два автономных варианта идеализированного проекта: один с учетом и другой без учета ограничений, налагаемых вышестоящей системой. Даже при наличии подобных ограничений, однако, большинство систем можно перестраивать радикально.
Проект, игнорирующий ограничения, желательно разрабатывать первым. Это уменьшает вероятность, что ограничения, обусловленные внутренними факторами, будут приняты за внешние. Такая подмена встречается очень часто. Когда вариант с учетом ограничений готов (после разработки проекта, не связанного ограничениями), каждое ограничение, вызвавшее какие-либо сокращения в проекте, следует проверить с соответствующими властями в системе более высокого порядка, дабы удостовериться, что такое ограничение действительно существует. Если существует, то, прежде чем согласиться с ним, необходимо тщательно изучить возможность обойти его. Большинство ограничений «дырявы», но «щели» редко бывают очевидными.
Например, одно государственное учреждение в развивающейся стране включило в идеализированный проект самого себя использование исследовательской группы из иностранных специалистов. Однако правительственными постановлениями запрещалось привлечение зарубежных консультантов государственными учреждениями. В то же время университетам, полностью финансировавшимся государством, разрешалось нанимать таких консультантов, а государственным учреждениям — привлекать эти университеты. Поэтому помощь иностранных специалистов данное учреждение могло получить, заключив соответствующие соглашения с местным университетом.
Если различие между вариантом, учитывающим ограничения, и вариантом, не учитывающим их, незначительно, то ясно, что будущее системы в большой мере находится в ее собственных руках. Если это различие велико, тогда основной заботой на остальных
стадиях процесса планирования будут изменения в системе, частью которой является данная.
Вариант идеализированного проекта, не учитывающий ограничений, следует дополнять описанием предполагаемых изменений системы (систем), содержащей данную, того, как они будут происходить и почему. Затем оба варианта идеализированного проекта части корпорации передаются на уровень корпорации в целом. В этом случае различия между корпорацией как целым и ее частями могут стать объектом приложения объединенных усилий разработчиков. Иногда такая процедура побуждает родительскую организацию разработать идеализированный проект и для себя.
Если идеализированный проект разрабатывается одновременно для семейства систем — системы, подсистемы, подподсистемы и т. д., усилия этих организаций необходимо объединять и координировать. Это достигается созданием плановых советов, описанных в гл. 3.
Похожие рефераты:
