Модель прикладной задачи. Модели ролевых функций

"Не чувствительность" модели менеджмента к содержанию прикладных задач означает отсутствие принципиальных отличий менеджмента качества от общего менеджмента бизнес-объекта. Именно поэтому происходит сращивание методов объектного менеджмента (MBO) и методов всеобщего управления качеством (TQM), которое наблюдаются с последнего десятилетия прошлого века [16].
Объективные закономерности общественного развития таковы, что по мере своего совершенствования, менеджмент качества будет все решительней стремиться заменять собою (поглотить) менеджменты иных видов деятельности бизнес-объекта.
"Хартия Европейского качества" должна быть прочитана как заявление о такой перспективе. В поддержку предположения о "всепоглощающем" характере менеджмента качества можно сослаться еще на мнение д-ра Р.С.Джойса, вице-президента компании Истмен Кэмикл, США.
Его компания в 1993г. была удостоена престижной премии М.Болдриджа за успехи в сфере управления качеством. Этот авторитетный специалист, впрочем, как и многие другие, считает, что "... качествоне отдельная система, это и есть сама система, то есть, управление качеством это управление работой всей организации7".
Будет ли менеджмент общим, финансовым, экологическим или каким-либо еще, это зависит только от состава прикладных задач, на которые распадается целевая программа. В данном случае на рис.1 перечислены прикладные задачи, связанные с качеством продукции, поэтому блок-схема относится к менеджменту качества.

Переход к другому виду менеджмента будет означать замену перечня прикладных задач другим списком. При этом блок-схема менеджмента не изменится.
2.2 .

Модель прикладной задачи. Модели ролевых функций

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

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

Каждому из направлений соответствует определенная ролевая функция; ее субъект автоматически становится официальным решателем прикладной задачи. Содержание живого труда пяти решателей прикладной задачи и статус каждого из решателей - субъектов ролевых функции показаны в табл. 2. Распределение живого труда между официальными решателями прикладной задачи Таблица 2

Характер деятельности, направленной на решение прикладной задачи	Статус субъекта ролевой функции
Организационная и техническая подготовка решения прикладной задачи. Проектирование оптимального состава прикладной системы ресурсов. Компиляция модели функций и свойств прикладной системы ресурсов. Постановка субзадач. Управление процессом решения прикладной задачи. Систематический контроль качества и результатов труда решателей прикладной задачи.	Администратор
Разработка технологии решения прикладной задачи. Обеспечение удовлетворения общих требований.	Технолог
Трансляция на уровень решателей прикладной задачи прикладных требований, обеспечение их выполнения.	Планировщик
Оперативная работа по реализации технологии решения прикладной задачи.	Оператор
Инспекция процедур решения прикладной задачи. Контроль выхода задачи, ведение записей о качестве выхода прикладной задачи, на основании которых принимают решение о передаче продукта задачи в инфраструктуру (выпуск) или на переделку.	Инспектор

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

Ролевую функцию Администратора прикладной задачи задает (назначает, проектирует) и персонифицирует вышестоящее руководство, которое выступает в роли постановщика прикладной задачи. Администратор получает регламент своей ролевой функции из рук вышестоящего руководства и автоматически становится связующим звеном между руководством и коллективом решателей прикладной задачи.

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

Прикладные

требования,

подлежащие

трансляции

Инструктивный раздел

на уровень

регламента

оператора

Директивный

раздел

регламента

Выпуск

Запись о качестве продукта

задачи

Выход задачи

Рис.2. Обобщенная схема решения прикладной задачи. Модель сети процессов .

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

Именно из частных моделей администратор компилирует модель функций и свойств прикладной системы ресурсов. Унифицированный алгоритм компиляции этой модели можно представить следующей схемой:

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

аттестуемые константы;	модифицируемые константы;
управляемые параметры;	констатируемые параметры.

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

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

В таком случае инструктивный раздел регламента можно заменить ссылкой на документ Системы НТД. Директивный раздел регламента Администратора содержит разъяснения, касающиеся использования универсального алгоритма в условиях конкретной прикладной задачи.
Рассматривая деятельность Администратора как процесс, можно увидеть, что выходом процесса является инструктивный раздел регламента Инспектора и регламент Технолога. Таким путем Администратор: а) утверждает свое административное право руководить действиями субъектов этих ролевых функций, б) исполняет обязанность направлять и координировать деятельность Технолога и Инспектора и тем самым создает в группе решателей прикладной задачи основу единого подхода к ее решению.
2.2.2 Обобщенный алгоритм реализации целевой функции Технолог
Составленный Администратором для Технолога регламент (вход процесса), предусматривает построение Технологом рабочих моделей ролевых функций Планировщик и Оператор (если этих моделей не существует в готовом виде, например, в форме СТП). В соответствии с ними, Технолог разрабатывает инструктивные разделы регламентов Планировщика и Оператора (выход процесса)
В составе данных, с которыми работает Технолог, находится сводный перечень параметров/констант, в котором Администратор уже произвел свои "вычеркивания". В общих чертах алгоритм деятельности Технолога соответствует следующей схеме:

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

2.2.3 Обобщенный алгоритм реализации целевой функции Планировщик
Действия планировщика завершают планирование производства продукции, предусмотренного Программой. После описанных выше "вычеркиваний" в исходном списке параметров/констант остаются лишь те, управление которыми требуется для удовлетворения прикладным требованиям.

Предписанные значения этих параметров/констант и/или законы управления значениями параметров устанавливает (задает, описывает) Планировщик. Для чего он должен извлечь необходимые данные из Системы НТД, где такие данные разбросаны по всевозможной конструкторской, технологической документации, ТУ и иным нормативно-техническим документам.
Путь в Систему НТД и адреса нужных данных указал Технолог в инструктивном разделе составленного им регламента Планировщика. Там же он дает (указывает) алгоритмы трансляции данных на профессиональные уровни Оператора и Инспектора.
Именно эти алгоритмы Планировщик представляет в виде директивных разделов регламентов Оператора и Инспектора.
2.2.4 Обобщенный алгоритм реализации целевой функции Оператор
Функция субъекта ролевой функции Оператор состоит в исполнении директивного раздела регламента, составленного Планировщиком. При этом технология труда Оператора должна отвечать требованиям, сформулированным Технологом в инструктивном разделе регламента Оператора.
Кроме того, Оператор ведет записи результатов самоконтроля и регистрирует значения констатируемых параметров в таких формах, которые заданы его регламентом.
2.2.5 Обобщенный алгоритм реализации целевой функции Инспектор
В регламенте Инспектора содержится исчерпывающая информация о том, какие характеристики выхода прикладной задачи надлежит контролировать, указаны методы контроля. А так же приведены требования, на соответствие которым должен проводиться контроль, указано, как оформлять записи о качестве и куда, в зависимости от результатов контроля, направлять выход прикладной задачи.

Классификация ролевых функций

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

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

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

Задание (наряд) является организационно - распорядительным документом; форму этого документа, а также порядок составления, движения, учета и хранения устанавливает Система СОМ бизнес-объекта. Оформленное по установленным правилом задание, становится объектом СУБД производственной деятельности бизнес-объекта.
Сведенные вместе инструктивная и директивная части образуют регламент ролевой функции9.
Эвристическая ролевая функция состоит в решении конкретной задачи заданного класса. Инструктивный раздел регламента эвристической ролевой функции существует в форме общих указаний на то, в каких пределах субъект данной эвристической ролевой функции оказывается решателем творческой задачи. Основой для ее решения является интеллектуальный потенциал субъекта ролевой функции (т.е. знания и практический опыт), свойства конкретной инфраструктуры, сумма внутренних политик бизнес-объекта и бытующие в нем производственные отношения.

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

Руководящие методические материалы (РТМы) являются разновидностью СТП и после их утверждения становятся объектами Системы НТД.
Директивная часть регламента есть персонифицированное предписание субъекту эвристической ролевой функции, в котором работодатель ставит конкретную задачу, указывает ограничения в выборе средств и условий ее решения, а также критерии оптимальности искомого решения; задает форму представления результатов труда и предопределяет процедуру доказательства состоятельности найденного решения. Предписание, после его утверждения в установленном порядке, становится объектом той или иной СУБД.
В тех случаях, когда решаемая эвристическая задача является уникальной (то есть, не относится ни к одному из выделенных (привычных) в бизнес-объекте классов эвристических задач), указания и
предписание на решение формулирует постановщик эвристической задачи. Форму регламента10, правила его составления, верификации и актуализации устанавливает Система СОМ.

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

Должностная инструкция является объектом СУДБ внутренней деятельности.
Директивную часть регламента ролевой функции, ставшей служебной обязанностью, определяет и осуществляет сам субъект служебной обязанности в соответствии с суммой действующих политик бизнес-объекта, пониманием доводимых до него стратегических и оперативных целей высшего руководства бизнес-объекта. При необходимости, в соответствующем разделе должностной инструкции предписывается, в какой форме субъект служебной обязанности должен документировать и актуализировать сформулированную самому себе директивную часть регламента ролевой функции и как фиксировать и представлять на инспекцию результат исполнения служебной обязанности11.
Ролевая функция Администратор прикладной задачи по типу деятельности ее субъекта может относиться к служебным обязанностям или к типу эвристических ролевых функций. Ролевые функции Технолога, Планировщика и Инспектора по большей части предполагают эвристическую деятельность своих субъектов.

Ролевая функция Оператор чаще всего исполняется рутинным трудом.
Ролевые функции допускают совмещение: за одним работником может быть закреплено несколько ролевых функций. Факт совмещения ролевых функций не влияет на их содержание. Этому есть очевидное объяснение; в самом деле, содержание ролевых функций порождено функциями и свойствами прикладной системы ресурсов, а не субъективными качествами исполнителя ролевой функции.

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

В любом случае, официальный исполнитель ролевой функции является гарантом качества процесса и результата исполнения закрепленной за ним ролевой функции.
2.4

Логическая структура бизнес-объекта как форма представления модели системы менеджмента качества

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

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

В то время как на следующем, (n+1) уровне детализации в этом элементе становятся видными включенные (вложенные) в него элементы (субэлементы).

Содержание раздела