Комментарии 1
Метазнания = знания о знаниях.
Знания об одном и том же «ручном» процессе:
- в регламенте;
- в голове у исполнителя процесса (при этом он, зная, как нужно сделать, делает иначе).
Знания об одном и том же «автоматическом» процессе:
- код (возможно даже с комментариями), понятный только машине;
- рабочая документация на программу (она может не синхронизироваться с кодом, т.е. может не совпадать).
Еще есть знания о том же процессе, но со «стороны» - это как окружение полагает, как работает процесс.
Полагаю, что для «ручных» процессов «Явные знания» могут быть в трех «хранилищах»:
- знания «из мира идей»;
- регламент по процессу;
- «голова» исполнителя в процессе (его понимание алгоритма и бизнес-правил).
Рассмотрим простой процесс \ алгоритм. Знания «из мира идей» - это в целом образ знаний (образ стула обычно всем понятен). Это абстракция, но она есть, хоть обычно не полная и не подробная.
В реальном процессе образ знаний проецируется на «мир вещей»: часть знаний «упакована» в регламенте по процессу. Часть знаний этого регламента «подгружено» в «оперативно-запоминающее устройство» исполнителя – человека (память человека). Если вдруг что-то он подзабыл, то может снова почитать регламент и догрузить. Обычно текстовые регламенты – не отличаются логичностью (последовательности изложения), имеют «много букв», сложно найти что нужно и некогда читать. Есть графические регламенты, но там тоже много проблем.
В итоге исполнитель - человек только частично владеет информацией, спроецированной из «объективной составляющей». Сотни тысяч (а может и миллионы) страниц регламентов одной крупной гос-компании, особенно из отрасли сильно «за регламентированной», например, госбанки, имеет основную цель не путеводителя по процессу для его исполнителей. Регламенты по 100-300 страниц нужны обычно для двух задач: а) найти крайнего если «что-то пошло не так» б) предъявить регулятору при проверке: при этом, такой «регламент для регулятора» содержит много фраз из документов самого регулятора, но понять, как устроен процесс – почти невозможно.
Мы говорим о «процессных регламентах», где описаны шаги процесса. Верхнеуровневые документы, типа политика и положение – фиксируют некие общие концепты, которые часто не позволяют определить, а что конкретно нужно делать.
Часто работает такой принцип: большой начальник говорит малому начальнику: «делай как хочешь (не важен сам процесс), но выдай хороший результат». Тут вообще знания о процессе могут замыкаться внутри подразделения малого начальника и не выходить наружу. Неявные знания могут быть вообще только в голове одного исполнителя. Большому начальнику «если что» проще на рынке взять нового малого, если предыдущий не справился.
Такой способ, часто достаточно эффективен и на новый экземпляр процесса может применяться логика (алгоритм) отличная от предыдущего экземпляра процесса. В таком случае, если по роли меняются исполнители, то вмете с ними часто и меняются алгоритмы процессов. Отсутствуют накладные расходы (обычно они значительные) на формализацию процесса.
Иное дело со знаниями в ПО. Автоматические операции в ИТ-системах подразумевают: когда человек нажал кнопку «выполнить», то происходит набор автоматических операций. Алгоритм процесса зашит в код ПО. Главное: если нет сбоев, то исполнение будет ровно как указано в коде. Правда сам пользователь обычно не знает, что же конкретно происходит по «нажатой кнопке»: эксплуатационная документация также объемна и может содержать другую логику, чем реально запрограммирована. Современный BPMN помогает, но не очень (в Low Code в реальности оказывается "много кода", и сам BPMS - ограниченного применения).
Фактически артефакты «из мира вещей» для ПО – это рабочая (не эксплуатационная) документация. Есть Process Mining, но он тоже пока не позволяет рядовому пользователю получить информацию: «как работает его процесс».
С одной стороны, четкий регламент и «ни шагу сторону» - это часто хорошо:
- в ручном процессе, исполнитель имеет четкую и подробную инструкцию;
- в автоматическом, весь рабочий день сводится к нажатию утром «одной большой Красной кнопки «Сделать работу»;
- в автоматизированном: жми весь день кнопку «далее».
Человечество обязано своим существованием некоторым людям, которые не доверились четкому регламенту, а смогли «капнуть глубже» (хотя подобное промедление могло привести к «не успели с ответным ударом»): Уильям Бассетт, Станислав Петров.
Итого: исполнитель-человек, может действовать:
А) «существуют явные знания в регламенте» - «перенос явных знаний в голову»: т.е. выполнить так «как задумано», причем объективно-формализовано задумано;
Б) «существуют явные знания в регламенте» - «перенос явных в голову лишь частично»: в регламенте все есть, но исполнитель выполнил их не так, при этом считая, что работал по регламенту (субъективные явные знания в голове не соответствуют объективным, т.е. формализованным);
В) «существуют явные знания в регламенте» - «в голове совсем иное»: зная, как нужно сделать, исполнитель сделал иначе (Уильям, Станислав), «подчерпнув» знания «из мира идей»;
Г) «не существуют / скудные явные знания в регламенте», т.е. регламент не четкий или «много букв» (иголка в стоге сена). Тут также несколько сценариев.
Проблема, как документировать сложные процессы «ручная составляющая + автоматическая», включая что происходит «по нажатию кнопки», - сегодня большая и нерешенная проблема. Обычно даже нет оценки «качества» регламентов, один из подходов: попробуйте по «пухлому» текстовому нарисовать схему процесса, например, EPC. Часто такие текстовые регламенты – всего лишь «обязательная» макулатура и назвать их «явными знаниями» - скорее всего, - не верно. Когда-нибудь появится ПО, которое сможет по текстовому регламенту автоматом построить схему процесса и тогда загрузив в него эти тонны обязательной нормативной «макулатуры» станет понятно их реальное качество.
«Корень зла» тут во многом в том, что компании не
публикуют свои процессы и не обмениваются по ним информацией.
Типы знаний в бизнесе: явные, неявные, встроенные