Посмотрим на роли участников применительно к информатизации (автоматизации) процессов. Как результат автоматизации для данной платформы переработки данных (в.т.ч. нетиповой) создаётся описание деятельности как комплекс инфопрогов и инструкций оператору. Инфопроги воплощены в форме программного текста (машинного кода, макросов) со встроенными данными - сообщениями обратной связи в контуре "человек-машина".
Более точно, встроенные данные имеют в общем три назначения: для получения целевых данных (как-то: константы предметной области - числа "пи", Авогадро и т. п.; константы/переменные параметризации расчётов; настройки режимов; и т. д.); для взаимодействия с оператором (тексты/подтексты сообщений; настроечные параметры протоколов обмена; и т. д.); для взаимодействия с предметной средой (то же).
Инфопроги выполняются по инструкциям на платформе для получения результата - целевых данных (документов/сообщений человеку, сигналов управления объектами). Эти данные могут сами быть конечным продуктом и/или управлять производством конечного продукта — материального и/или опять же данных.
В принципе возможно, что информатизация проводится для более эффективной организации труда людей без дополнительной автоматизации. Тогда создаётся только новая модель процессов труда; она м.б. основана на новом (более прогрессивном) представлении (типизации/атрибуции) объектов (предметов и средств) труда. Здесь результатом будут "педантические" (алгоритмически строгие) описания манипуляций с ручным инструментом и/или машинами (станками, приспособлениями) над "педантически" (датаматически строго) описанными объектами (вещами, данными).
Пример - описание технологии по стандартам ЕСТД (ГОСТ 3.*) над материальными изделиями, описанными по стандартам ЕСКД (ГОСТ 2.*).
Итак, речь идёт о производстве данных (документов, сообщений), обеспечивающих деятельность людей и/или работу машин.
Кто здесь является производственником? При автоматизированной ИТ - вроде бы машина (инфорсима), а на самом деле также её пользователь - потребитель, заказчик изделия (образует с машиной систему "персонал-компьютеры-механизмы" для главного назначения - "чтобы от работающего изделия толк был"). Ещё одна категория участников процесса - эксплуатационник, системный оператор (тоже образует с машиной систему "персонал-компьютеры", но уже для вспомогательного назначения - "чтобы изделие работало в нормальных условиях"). Также имеется администратор системы (банка данных) - решает вспомогательную задачу "чтобы условия работы изделия были нормальными".
Всё это напоминания тривиальные; важно лишь, что это действующие лица фазы применения полного ЖЦ, а нас интересует и фаза создания.
Кто тогда технолог? Системный аналитик — специалист по процессам разработки на имеющихся платформах.
Программист, исходя из этого проекта, создаёт (м.б. лишь подбирает и конфигурирует) систему инфопрогизделий для конкретной платформы; если только инфопрогрешений недостаточно, то подключается также схемо(системо-)техник, чтобы создать оригинальную аппаратную часть (конфигурацию) платформы (и связанные с ней элементы деятельности); если используется сложная модель данных - подключается инженер по данным, создающий их модель (схему БД). Эти специалисты в традиционной промышленной терминологии - инструментальщики.
А кто же здесь конструктор, которого Грабин гордо зовёт носителем технического прогресса? Не кто иной, как аналитик-эксперт в предметной области заказчика - именно он знает, как "стреляет информатическая пушка" т.е. достигается результат деятельности. И он проектирует архитектуру инфорсимы как ПМК, деятельность оператора и функционирование средств его труда (информатического - как процесс "производства данных" на информашинах).
При автоформализации знаний или формализации с вовлечением конечных пользователей (на чём основан менеджмент качества) этот эксперт есть сам заказчик системы автоматизации.
Вроде бы вещи тривиальные, и каждый скажет "так это давно так и есть". А так ли? Посмотрим, каково положение дел в реальности...
С традиционной т. зр. ИТ-сферы, как целевой объект создания рассматривается средство автоматизации деятельности, часто широкого применения. Тогда за конечный продукт принимается реализация описания деятельности. Здесь (если ограничиться только программной реализацией) производственник - это программист-кодировщик, технолог - специалист-организатор среды разработки на конкретной платформе, инструментальщик - создатель (поставщик) сред и платформ разработки (а равно и услуг по их сопровождению), конструктор - аналитик, ставящий задачу за заказчика (обычно - на основе анализа предпочтений пользователей, их усреднения).
Т.о., производство средств производства организационно разобщено с производством конечного продукта (в данном случае - целевых данных). Это подходит, чтобы выпустить инфорсиму "на общий случай" для абстрактного, усреднённого пользователя, но неэффективно, когда нужно её настроить на конкретный производственный процесс заказчика. Как следствие, появляются многочисленные публикации типа: "Решение <таких-то задач конкретной предметной области> с помощью <такого-то типового инфопрога>". Само по себе это не хорошо и не плохо - важно, чтобы руководства отвечали конкретным задачам и появлялись своевременно.
Допустим ли вообще такой подход? Вполне, если речь идёт о выпуске типовых изделий; не случайно он проводится, в частности, у Джоэла Спольски, активно работавшего в MS. Более того, он продуктивен и при РБП как вспомогательный для поверки требований заказчика - и при заказной разработке не всё, что хочется, следует автоматизировать, иначе можно получить громоздкую систему.
Кто же в фазе создания таким образом ИТ-решения обычно пользователь? Просто оператор? Ан нет — публичность инфопрогизделий в большинстве случаев означает ограниченность их назначения и одновременно — неполную совместимость друг с другом. Не говоря уже о неполной гарантоспособности, которую недобросовестные ИТ-специалисты любят стыдливо именовать «неопределённым поведением» (undefined behaviour).
Поэтому для полного трудового процесса часто бывает необходимо стыковать инфопроги по данным, исследовать режимы работы и/или конфигурации для выбора результативных, устойчивых. Всю эту работу создатели негарантоспособных ИТ-решений великодушно возлагают на плечи эксплуатантов...
Фактически, если гарантоспособность орудий труда «как конечных продуктов» не обеспечена — то их эксплуатанты вынуждены становиться и конструкторами-технологами. По крайней мере, «из кубиков» - орудий как «чёрных ящиков». А если есть квалификация — то и полноценными «допроизводителями», также модифицирующими внутреннее устройство (и принцип действия) орудий.
Это не зависит от предмета труда — но попробуйте найти в документации на орудие материального производства ограничение ответственности типа: «мы не отвечаем за какие бы то ни было последствия применения нашего орудия по назначению». А в ИТ подобное сплошь и рядом...
Естественно, наиболее удобен для этого тип организации «кто-то для кого-то»; поэтому мы видим, как вокруг массовых негарантоспособных инфопрогов возникает целая сфера услуг «псевдоинжиниринга», основная деятельность в которой сводится к настройкам, стыковкам, «подъёмам» после крахов программ. Хорошо, если эти услуги можно свести к написанию руководств «о том, что не написано в справке», следование которым подтягивает гарантоспособность до нужного или приемлемого уровня. Хуже, когда продукту нужна постоянная или приходящая «нянька», нередко высокооплачиваемая... Тем более — когда крах продукта (и/или дестабилизирующее влияние его на другие продукты, на платформу) ведёт к потерям результатов труда и/или простоям средств производства.
Итак, определение результата ИТ-проектирования как конкретных видов целевых данных, продуцируемых более эффективно и надёжно (за счёт новой реализации деятельности, возможно, на базе новой модели процессов и объектов), более естественно при решении конкретных меняющихся задач, и оно характерно для реинжиниринга.
Здесь пользователь становится, как положено, эксплуатантом, аналитик — создателем требований; поставщика сред разработки можем рассматривать как эксплуатационника вспомогательных средств деятельности (внешнего инструментальщика). На остальные роли (конструктора - разработчика изделий и процессов переработки у заказчика, технолога - создателя, производственника — программиста, инструментальщика — разработчика собственных сред) это дополнение не влияет. Несущественно и совместительство разных категорий инструментальщиков между собой и с технологами.
Естественно, инструментальщик, технолог и остальные м.б. отдельными от заказчика оргсистемами (юрлицами), работать на ряд заказчиков, но они в таком понимании всё равно обслуживают конкретное производство каждого заказчика и тесно с ним взаимодействуют на основе сообща формируемой модели деятельности.
Ну и наконец — для чего всё это говорится в связи с формализацией знаний? А дело в том, что любая МФЗ, как мы помним, подразумевает реализацию. Полностью ручное «говорение» на языках представления знаний (например, графит-семейства) или максимально автоматизированное — неважно. Важно, что создаётся среда поддержки — хотя бы в виде моделей процессов формализации вручную (обычно имеющих форму методической документации). И эти модели являются таким же изделием (ну а среда автоматизации как комплекс инфопрогов и документации на них - тем более). И её создание подчиняется рассмотренным выше условиям.
В частности, хорошо уже знакомый многим «опенсорс» как форма организации пожицикла инфопрограммных изделий в зависимости от наличия и характера обратной связи с пользователями относится к публичному или заказному типу организации; а при высоком уровне взаимодействия (обычно на основе добротных спецификаций) может возникать ситуация «мы для нас», когда одни и те же люди и пользуются софтом, и разрабатывают его — своего рода коллективный вариант утилитарной организации.
Так что реализуя графит-языки, стоит подумать, как построить дело — если не сразу, то по мере работы.
Есть и ещё одна вещь, связывающая организацию дела с формализацией — сами языки. Помните, при описании ролей мы постоянно повторяли «при коллективном... - на установленных языках»? Имелись в виду как раз языки представления знаний о той или иной части дела. Взаимодействующие друг с другом и/или с машинами люди должны равно понимать этот язык. Для машин язык определяют их создатели и доводят определения языков до других участников (операторов эксплуатации, сервиса, обеспечения).
В каждой предметной области существует свой профессиональный язык. И помимо базиса графит-языков, рассматриваемого нами, среда поддержки формализации должна позволять «говорение» на этом — предметном — языке (зарубежные ИТ-специалисты обычно называют их domain-specified languages, DSLs). Хотя бы на уровне «букв», из которых пользователь среды будет складывать «слова». В графике «буквы» - это базовые примитивы (автофигуры).
Возможна «интеграция наложением», когда среда интегральной формализации деятельности связана по данным с частными, специализированными предметно (напр., на механике или гидравлике, транспорте или связи) и/или функционально (напр., на расчётах или управлении). Тогда возможно включение результатов из частных сред в документы интегральной с добавлением специфических данных (хотя бы просто наложением графики и текста).
Высший уровень — интеграция в точном смысле, когда каждый предметный язык просто реализован в единой среде. Возможно, в виде языкового модуля, подключаемого при необходимости. Однако при этом встаёт вопрос и о реализации предметно-специфичных операций (тех же расчётов, моделирования). Возможный путь — когда сохраняется набор частных сред, реализующих содержательные операции, а интегральная просто может работать с их форматами данных, включая объединение на общей диосцене.
Здесь мы придерживаемся подхода «наложением». При этом интегральная среда поддержки (в частности, приложение автоматизации) не должна замещать предметно-специализированных.
Прежде чем создавать собственное приложение поддержки, также нужно определиться с его ролью по отношению к поддерживаемым предметным областям.