О системе

Данная страница посвящена тому, КТО, ЗАЧЕМ и КАК создавал Систему комплексной автоматизации "Оберон". Тому, что из этого получилось, посвящены другие страницы этого сайта.

Кто

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

Их, традиционных методов, насколько известно, два.

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

Второй метод предполагает приобретение солидной тиражной системы автоматизации, за которой стоит солидная софтверная компания, имеющая множество внедрений.

Собственный опыт (8 лет первым методом и 5 - вторым) не позволяет авторам определиться, какой из методов лучше. Скорее, они склоняются к выводу "ОБА ХУЖЕ".

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

Второй метод (внедрение тиражной системы) на первый взгляд сложнее в реализации. Столкнувшись с необходимостью внедрения "коробочного" решения, прикладные специалисты первым делом обнаруживают, что все совсем не так, как они привыкли. И дело не в непривычном интерфейсе пользователя (хотя это тоже может стать проблемой). Дело в том, что тиражная система с одной стороны неизбежно накладывает свои ограничения на технологию построения бизнес-процессов (всё на все случаи жизни реализовать невозможно), с другой же стороны, расчитанная на реализацию максимально широкой трактовки реализованных бизнес-процессов, заставляет вводить массу реквизитов и выполнять множество действий, очень нужных на других объектах автоматизации, но только мешающих на данном, а вот для реализации изюминки "нашего изобретения" как раз данных и не хватает. На второй взгляд, ситуация начинает выправляться: за тиражной системой, как правило, стоит мощная компания, с налаженной аналитической службой, способная "поднять" любое решение. На третий же взгляд все становится совсем плохо. Дело даже не в том, что все ваши ноу-хау немедленно становятся достоянием рынка. Беда в том, что тиражная система - означает, что система имеет множество "точек настройки", как правило, встроенный язык, да еще и, глядишь, не один (отдельно язык формульный, отдельно - процедурный, отдельно - язык построения выходных форм). В результате, уже к моменту завершения внедрения на объекте автоматизации система сильно отличается от той, что была куплена в "коробке". Со временем она отползает еще дальше. В результате, прикладной программист, неизбежно появляющийся на объекте автоматизации для обслущивания этой системы, оказывается связан решениями, принятыми другими людьми при создании "коробки" и некоторые вещи не может реализовать по независящим от него причинам. С другой стороны, и фирма-разработчик за действия этого программиста уже не может отвечать, и если, упаси господь, с ним что-то случится - помочь уже ничем не сможет. Цугцванг.

Что же делать бедному владельцу объекта автоматизации? Один из авторов как-то сформулировал свое видение ситуации следующим образом: "Если бы я мог однозначно и аргументированно ответить на этот вопрос, Билл Гейтс точил бы у меня в офисе карандаши!".

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

Зачем

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

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

Для выполнений такой работы понадобился инструмент. Попробуем сформулировать вкратце черновой набор требований к этому инструменту.

Как

Попробуем представить себе человека, пришедшего на незнакомый объект автоматизации с задачами, аналогичными изложенным выше. Оставим пока в стороне требования к его профессиональной подготовке, к тому, какими навыками он должен обладать, чтобы за конечное время понять, чего пытаются добиться на объекте автоматизации и как этого можно добиться. Пусть он смог вынести с объекта автоматизации некоторое первое приближение к пониманию деталей предметной области. Что ему с этим пониманием делать? Писать аналитические записки? На UML? А зачем? Отнести специалистам объекта автоматизации? И что они с этим будут делать? Читать? Ну-ну...

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

Потому будет очень полезно, если на вторую встречу он возьмет с собой действующую модель того, что он вынес с первой встречи. Этакий прототип. У этого прототипа может еще не быть половины информационных полей, может быть не подключено и не заполнено ни одного справочника, не говоря уже об онлайновой справочной системе. Но ГЛАВНОЕ из того, что он вынес из первой встречи, должно быть прототипировано. И в последствии этот прототип должен нечувствительным образом перейти на рабочий компьютер прикладного специалиста, постепенно дополняясь функиями и обрастая справочниками. Со временем будут подточены падежи на экранных формах и нарастет онлайновая справочная система, но это уже не принципиально. Принципиально, что очень полезно для дела, если прикладные специалисты сразу видят, что разговоры, которые они разговаривают, не уезжают в светлую даль, чтобы потом, спустя месяцы если не годы, когда все уже много раз изменится, вернуться к ним в виде многотомных трактатов, которые все равно никто читать не будет, а сразу превращаются в нечто осязаемое, которое можно покрутить и покритиковать, и оно будет подправлено в соответствии с этой критикой.

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

Именно для того, чтобы удовлетворять этим и еще некоторым другим требованиям, и создавалась Система комплексной автоматизации "Оберон".

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

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

Но это, как писали А.& Б. Стругацкие в неподражаемом романе "Понедельник начинается в субботу", уже со-овсем другая история.

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