CADmaster

Машиностроительные предприятия традиционно рассматривают в качестве объектов автоматизации несколько предметных областей: техническую подготовку производства, производственное планирование и учет, финансово-бухгалтерскую деятельность. Столь же традиционно в каждой из этих областей представлены предложения разработчиков программного обеспечения: инструменты автоматизации, а также предложения консультантов — поставщиков услуг по внедрению данных инструментов. Существует, тем не менее, одна особенность, которую хотелось бы подчеркнуть. Если поставщики ERP-решений в процессе внедрения традиционно практикуют проектную организацию работ (и услуги консультантов также традиционны), то подобной устойчивой практики в области автоматизации подготовки производства пока не сложилось.

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

Следуя подобной логике, можно предположить, что внедрение одного и того же ПО на предприятиях одинаковой отраслевой принадлежности как минимум должно быть типовым. Зачем же тогда предприятия в ряде случаев привлекают к выполнению проектов сторонних консультантов? Казалось бы, можно обойтись собственными силами или минимальным участием разработчиков, призванных обучить группу будущих пользователей и обеспечить методическое сопровождение процесса…

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

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

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

• Поставщики решений изначально ограничены возможностями ПО, но не всегда в состоянии адекватно оценить влияние этих ограничений на конечный результат в реальных условиях конкретного предприятия. Адекватная оценка предполагает серьезную исследовательскую работу, которая требует финансирования и времени, а на этапе принятия решения, как правило, нет ни того ни другого. Более того, даже при наличии серьезного предварительного анализа, выполненного высококвалифицированными специалистами, зачастую уже по ходу выполнения проекта выявляются нюансы, заставляющие вносить в него очень серьезные изменения. Незначительная деталь, мелочь, которой поначалу не придали значения ни эксперты предприятия, ни разработчики, приводит к пересмотру базовых понятий и соглашений, лежащих в основе решения. Дьявол, как известно, прячется в деталях…
• Представление предприятия о сути предлагаемого решения, а также о возможностях программного обеспечения основывается в лучшем случае на результатах тестирования и пилотных проектов, а чаще на декларациях поставщиков решений и их умении проводить презентации. Зачастую многое зависит просто от личного обаяния продавца. Даже при абсолютной добросовестности поставщика решения, наличии у него серьезного опыта и искренней заинтересованности в получении продуктивного результата неизбежно складываются два отдельных понимания как цели проекта, так и способов ее достижения. У каждой стороны — свое. Как результат — ложные ожидания у предприятия и ложная уверенность поставщика в том, что цель будет достигнута.

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

Во-вторых, недостаточно только настроить ПО. Требуется «выстроить» взаимодействие служб предприятия в процессах конструкторского и технологического проектирования, а это связано с принятием ряда технических и управленческих решений. В каждом конкретном случае задача поставщика — найти и предложить оптимальные в данных условиях решения, опираясь на собственный опыт и глубокое понимание особенностей предприятия, а задача предприятия — провести эти решения в жизнь, внедрить их. Чем более «децентрализованный» способ подготовки производства практикуется на предприятии, тем более трудоемкой и сложной оказывается эта задача.

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

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

• в процессе выбора руководствоваться принципом разумной достаточности: базовый функционал программы должен обеспечивать принципиальную возможность сквозной и непрерывной поддержки автоматизируемых процессов;
• выбранный инструмент (ПО) обязательно должен предоставлять возможность «глубокой» настройки и доработки — встроенные средства программирования, API и пр.;
• необходимо профессиональное владение выбранным инструментом. Уже имеющийся опыт его применения позволит в процессе внедрения находить новые, нестандартные решения, зачастую даже не предусмотренные разработчиками.

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

Необходима также готовность к изменениям в ходе проекта — со стороны как предприятия, так и поставщика решения.

Попытаюсь проиллюстрировать приведенные тезисы на примере построения системы автоматизации конструкторской и технологической подготовки производства для одного из базовых предприятий агрегатостроения авиационной отрасли. Процесс построения системы осуществлялся силами специалистов отдела инженерного консалтинга компании CSoft.

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

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

Подразделения предприятия, хотя и представляют собой единый организм, всегда предпочитают блюсти собственные интересы. Соответственно, на старте проекта различные службы представляли его результат, скажем так, неодинаково:

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

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

Нельзя допустить, чтобы ERP изначально формировала базу на основании данных ИВЦ, так как впоследствии из-за различий в структуре данных будет очень трудно (если вообще возможно) обеспечить взаимодействие систем, — а такие различия неизбежно возникнут. ERP должна сразу же питаться данными из TechnologiCS — это единственный вариант, который сможет обеспечить дальнейшую совместную работу.

Сформировать базу TechnologiCS можно на основе тех же данных ИВЦ, но эта информация вряд ли будет понятна сотрудникам инженерных служб: в базу ИВЦ она заносилась с конструкторских и технологических документов, претерпевая при этом некоторые изменения, в основном диктуемые логикой работы системы. Следовательно, вид и структура информации уже не соответствовали традиционным представлениям авторов — конструкторов и технологов.

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

Первая очередь:

• импорт информации из базы данных ИВЦ в TechnologiCS;
• автоматизированное преобразование данных в TechnologiCS, обеспечивающее потребности ERP, разработка и отладка механизмов передачи данных в производственную систему;
• разработка и внедрение упрощенных временных регламентов, позволяющих поддерживать актуальность данных в TechnologiCS, то есть осуществлять учет изменений. Важно, что при этом учет осуществляют «хозяева» информации — конструкторы и технологи.

Результат — возможность функционирования ERP на самом начальном этапе автоматизации КТПП, но уже с использованием постоянного фундамента (структуры данных). Начальное наполнение базы по всему номенклатурному перечню в дальнейшем позволило одновременно запустить несколько параллельных процессов в рамках внедрения как TechnologiCS, так и ERP и тем самым существенно ускорить выполнение всего проекта.

Вторая очередь:

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

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

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

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

Тезисы второй и третий. В рассматриваемой предметной области крайне затруднительно применять формальные способы моделирования и выстраивания процессов.

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

• Программы (инструменты для автоматизации подготовки производства) традиционно не имеют собственных приложений (процессных «движков»), позволяющих моделировать и реализовывать процессы. В нашем распоряжении нет чего-то подобного ARIS/SAP. Есть отдельно ARIS (или подобные средства), отдельно TechnologiCS. Получается, что модели процессов могут быть использованы практически только для их визуального анализа и согласования.
• Предметная область, о которой идет речь, характеризуется устойчивым кругом традиций, в том числе и традиций мышления. Традиции прочно опираются на уже не обязательные к применению ГОСТы. Это совсем неплохо, более того, позволяет формально подходить к соответствующим процессам и составляющим их функциям. Если бы не одно «но» — упомянутые традиции четко ориентированы на бумажные документы и управление ими. Внедрение электронных средств работы с информацией, основанных на базах данных, предполагает изменение самой сути документа: из «носителя информации» он становится лишь ее отображением в форме, привычной для пользователя. Соответственно, должно меняться и отношение к электронному документу — при выстраивании процессов объектами управления должны становиться информационные объекты базы данных (а они далеко не всегда однозначно соотносятся с документами). При этом документы — производные этих объектов — отображают информацию (для внутреннего использования), а также служат носителями соответствующего юридического статуса при общении предприятия с внешним миром.
• Данная метаморфоза очень трудна для восприятия конструкторами и технологами. Попытки совместными усилиями выстраивать процессы «как должно быть» (даже если специалисты предприятия владеют соответствующими методиками и инструментами) показывают, что консультанты и специалисты говорят на разных языках. В большинстве случаев консультанты моделируют процессы, которые успешно проходят экспертизу специалистов предприятия, а далее выясняется, что каждый имел в виду свое. Ведь после реализации специалисты видят уже не абстрактные схемы, а понятные им документы, «работу» которых могут оценить в привычных для себя категориях.

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

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

Другими словами, оценка реализации процессов стала адекватной тогда, когда эксперты смогли анализировать результат в близких и понятных им категориях. Действительно, нет смысла разговаривать с технологами, употребляя слова «сущности» и «транзакции». Технологи — высококлассные профессионалы в совсем другой области. Если хочешь услышать профессиональный ответ — говори со специалистом на его языке.

Таким образом, задача выстраивания процессов и системы управления ими существенно выходит за рамки традиционного понятия «управление документооборотом». Успех ее решения зависит от опыта и квалификации консультантов, от наличия в их багаже набора опробованных типовых решений. В противном случае существует риск не попасть в цель с первой попытки — и переделывать работу…

Тезис четвертый. Адаптация любого программного обеспечения требует поиска нестандартных решений и серьезного программирования.

Выбранное предприятием в качестве инструмента автоматизации программное обеспечение TechnologiCS по праву считается одним из самых мощных и развитых средств для решения задач в области подготовки производства. Тем не менее объем доработок, выполненных по ходу проекта, очень велик. Важно, что система TechnologiCS, располагающая встроенными средствами программирования и развитым API, позволила это сделать.

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

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

1. Принятый на предприятии децентрализованный способ подготовки производства заставил отказаться от традиционного для TechnologiCS «сквозного» техпроцесса. Техпроцесс приобрел иерархию, оставшись сквозным только для перечня операций, выполняемых с данной деталью в данном цехе. Такая структура несколько усложнила всю конструкцию, но при этом позволила реализовать управление процессом разработки и взаимодействием подразделений в этом процессе, а также реальное управление правами доступа к информации. Металлургические техпроцессы, традиционно имеющие «описательный» вид, приобрели структуру, позволяющую использовать информацию для нужд производственного планирования, а также решать задачу баланса металла с учетом возврата и потерь.
2. Разработан уникальный механизм получения сводной конструкторской и технологической информации по изделиям с учетом всех изменений будущих периодов. В рамках этой задачи также решена проблема определения полной применяемости, соответствующей определенному извещению об изменении. В TechnologiCS для решения подобных задач обычно используется итоговая спецификация, но здесь по ряду причин от нее пришлось отказаться.
3. Разработана автоматизированная система управления процессами конструкторско-технологического проектирования и проведения изменений с использованием сложной структуры управляющих документов, включающая цикл проектирования инструмента и оснастки. Предложен и реализован механизм, позволяющий одновременно управлять двумя видами состава изделия — конструкторским и технологическим. Документы, традиционно получаемые из TechnologiCS в качестве отчетов, приобрели интеллект, помогающий пользователю в осуществлении процедур согласования и утверждения.
4. Разработан алгоритм взаимодействия с системой ERP, реализованы автоматизированные механизмы снабжения данной системы информацией.

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

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

Слово «консультанты» у многих вызывает отторжение (люди, вроде бы ни за что не отвечающие). Отторжение связано, как правило, с негативным опытом, а опыт, в свою очередь, порожден неправильно сформированными ожиданиями от результата деятельности консультантов.

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

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

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

Еще один вопрос, встающий перед предприятием, принимающим решение о привлечении стороннего ресурса: кто будет эффективнее — консультант или разработчик ПО? Рискну высказать мысль, которая может показаться крамольной: привлечение специалистов, профессионально занимающихся внедрением систем, эффективнее привлечения разработчиков этих систем. Вот несколько аргументов в поддержку такого вывода:

• Консультанты свободны в выборе инструментария — среди причин, заставляющих выбрать то или иное ПО, определяющими являются критерии проекта конкретного заказчика. Другими словами — у консультанта, в отличие от разработчика, всегда есть альтернатива.
• Консультанты владеют профессиональной компетенцией, находящейся за рамками знаний, связанных с разработкой ПО. Прежде всего это знания, связанные с проектной организацией работ, и умение применять их на практике.
• Консультанты способны смотреть шире, чем это требуется с точки зрения внедряемого программного обеспечения. Их задача — видеть «собственную» область автоматизации как часть всего автоматизируемого пространства, уметь построить проект внедрения в контексте общего решения задачи автоматизации предприятия, когда очередность и способы решения отдельных задач определяются прежде всего их влиянием на общий результат.
• Консультанты смотрят на программное обеспечение с точки зрения нужд пользователя, адекватно оценивают достоинства и недостатки. А с точки зрения разработчика скорее неверно действует пользователь, чем неправильно работает программа.
• Консультанты свободны от неоправданных ожиданий, что разработчик «доделает» программу под нужды предприятия. Поэтому они могут рассчитывать только на собственные силы и опыт, используя программное обеспечение в том виде, как оно есть. Тем более что доработки ПО, выполненные в рамках конкретных проектов, гораздо точнее настраивают его под нужды конкретного предприятия — в итоге заказчик получает практически «именное» решение.

Понимание этих причин позволило создать в компании CSoft специализированное подразделение — отдел инженерного консалтинга. Компетенция сотрудников отдела позволяет выполнять проекты в области автоматизации технической подготовки производства на предприятиях машиностроительной отрасли и ряда других, сходных с машиностроением по характеру производства.

Остается добавить лишь несколько слов — в качестве заключения.

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