Разработка АСУ - длительный процесс, в котором участвуют коллективы различного назначения, различной ответственности, подчиненности и даже имеющие свои цели, отличные от целей разработчиков. Например, руководство организации-заказчика заинтересовано в дешевой разработке с получением скорейшего эффекта от автоматизации, а у разработчиков - собственные научные и производственные планы. Иногда работники организации-заказчика считают, что автоматизация не очень-то и нужна (дескать, жили без нее - проживем и дальше), другие рассматривают необходимость взаимодействия с разработ чиками как помеху, мешающую им выполнять свои прямые обязанности, третьи беспокоятся, что в новых условиях они окажутся не у дел и т. п. В любом случае для сотрудников аппарата управления участие в создании АСУ - дополнительная забота, поэтому еще раз уместно отметить, что разработка АСУ, внедрение средств автоматизации не должны сказываться на выполнении организацией своих функций.
Во главе разработок АСУ должен стоять руководитель организации-заказчика, либо один из его заместителей, причем в больших системах целесообразно его освободить на это время от всех других обязанностей (хотя на практике такое удается осуществить крайне редко). Необходимость участия руководства организации в разработках АСУ связана с двумя основными моментами. Во-первых, внедрение ЭВМ часто требует внесения существенных изменений в систему, ее методы работы, структуру, документы и т. д., и только руководство организации может санкционировать подобные изменения и утверждать принимаемые проектные решения (бывают случаи, когда приходится обращаться и в вышестоящие инстанции). Во-вторых, опять-таки только руководство организации может обеспечить необходимое участие ее сотрудников в разработке АСУ и взаимодействие с разработчиками.
Руководитель, занимающийся вопросами внедрения вычислительной техники, должен быть в курсе хода разработок и утверждать все основные принципиальные решения. Часто такое утверждение носит формальный характер: утверждаются, «не глядя», все предложения разработчиков. Это одна из распространенных ошибок при разработке АСУ, нередко приводящая к негативным по следствиям. Обычно в группу руководства разработкой, которая рассматривает все принципиальные вопросы входят 5-7 ведущих работников организаций заказчика и разработчика.
Как уже говорилось, одна из первоочередных задач руководителя разработки АСУ - обеспечить проведение на высоком уровне обследования существующей системы и разработки технического задания, а затем и эскизного проекта. Для этого утверждаются соответствующие планы работ, составляются списки сотрудников организации- заказчика, информация от которых будет полезна при их разработке. Окончательную разработку технического задания и эскизного проекта не следует поручать слишком большому коллективу. Практика показывает, что группа из 4-5 человек вполне справляется с этой работой. Однако это должны быть наиболее компетентные специалисты из организаций заказчика и разработчика.
Как мы уже знаем, разработка АСУ ведется по подсистемам - структурным и функциональным. Во главе этих разработок также должны быть достаточно компетентные работники. Целесообразно, чтобы руководители разработок основных подсистем входили в руководящую группу по разработке всей АСУ. В процессе разработки отдельных подсистем приходится решать ряд вопросов, имеющих общее значение для всей системы, таких, как информационное взаимодействие отдельных подсистем, общая система классификаторов и нормативов, общие сервисные программы и т. д. Руководители должны обеспечить единство подхода при решении этих и подобных вопросов и учет интересов отдельных подсистем.
Разработка подсистем ведется по отдельным задачам, выбор которых и утверждение очередности их решения также входят в обязанности руководителей разработки автоматизированной системы. Разработка отдельных задач ведется группами системщиков и программистов, руководство должно обеспечить их увязку между собой. В процессе создания АСУ разрабатывается ряд проектов по отдельным задачам, подсистемам, всей системе. Эти проекты должны содержать конкретный материал, который нужно (и можно) внедрять. Практика же показывает, что это, казалось бы, элементарное требование не всегда выполняется, в то же время очевидно, что общие рассуждения внедрить не удается (отсюда также вытекает требование максимальной стандартизации и единообразия при написании всех проектов). Конкретности проектов или их частей (позволяющей их непосредственное использование) можно добиться, если заранее четко оговорить, какие материалы, в каком объеме и какого назначения считаются окончательными результатами и предъявляются к сдаче.