Файл для работы: personal22
Место внутреннего процесса в иерархии
Процесс отбора персонала относится к категории внутренних процессов. В отличие от сквозных процессов, ориентированных на внешнего клиента (например, разработка или поставка мебели), он не имеет входов, поступающих извне организации. Все его входы и выходы замкнуты внутри компании.
Каждый детализированный процесс связан с процессами верхнего уровня. На стратегической карте процесс отбора персонала является детализацией управляющего блока «Управление персоналом». Этот блок может делиться на подпроцессы: «Повышение квалификации», «Найм сотрудников», «Отбор персонала» и т.д. Показывать сразу всю модель верхнего уровня в одной длинной цепочке нецелесообразно -- её разбивают на группы процессов, чтобы сохранить читаемость и не смешивать уровни детализации.
Особенности моделирования внутреннего процесса
Главное отличие внутреннего процесса -- отсутствие внешних клиентов. Входы формируются внутри организации. В рассматриваемом примере входом служат заявки на персонал от начальников отделов. Этот объект имеет атрибутивный статус -- «подписанные заявки», который отображается в примечаниях модели. Такие атрибуты можно дополнять ссылками (линками) на внутренние регламенты, например на документ «Регламент подписания заявок на персонал». Ссылка размещается как атрибут объекта и делает модель информационно насыщенной.
В модели используются роли, а не должности. Объект «Ответственный за подбор персонала» описывает функцию, которую в разных экземплярах процесса могут выполнять разные должностные лица -- менеджер по персоналу, начальник отдела или рядовой сотрудник. При необходимости к роли можно дополнительно привязать перечень конкретных должностей.
Цепочка процесса и анализ описания
Модель строится по текстовому описанию «как есть». Шаги процесса:
- Событие -- наступление 25-го числа последнего месяца квартала. Оно активирует следующую функцию.
- Функция «Сбор заявок на персонал у начальников отделов» -- её выполняет ответственный за подбор персонала.
- Событие «Заявки собраны» -- фиксация завершения.
- Функция «Обработка заявок» -- на выходе формируются проект списка вакансий и пояснительная записка к нему. Если формат записки не описан, это фиксируется как недостаток исходных данных.
- Согласование материалов со своим начальником -- согласно описанию, руководитель отдела всегда согласовывает подготовленные документы. Никаких вариантов (например, отказ, замечания) в исходном тексте нет. Такая линейность является ошибкой описания. Любое согласование подразумевает решение, а не формальное подписание. Если альтернатива не указана, в модели добавляется примечание: «Не конкретизировано решение по согласованию вакансий. Уточнить.»
- После согласования начальником ответственный рассылает материалы трём заместителям генерального директора. Поскольку в описании фигурируют конкретные должности (заместители по различным направлениям), методологически верно скопировать их объекты из организационной диаграммы, но для упрощения можно временно использовать обобщённую роль «Заместитель генерального директора».
- Функция «Совещание по обсуждению кадровых потребностей» -- инициатором выступает ответственный за подбор, а участниками -- все заместители. Входом совещания служат проект списка вакансий, пояснительная записка и предложения от заместителя генерального директора (этот вход приходит из другого процесса, что отображается соответствующим потоком).
- Ветвление по итогам совещания -- в исходном тексте сказано: «Итогом совещания является утверждённый список вакансий». Вариант неутверждения не предусмотрен. Значит, совещание всегда утверждает список, что делает эту функцию формальной. Аналитик обязан зафиксировать гипотезу по ветвлению: добавить альтернативу «Список вакансий не утверждён», выделить её цветом и сопроводить комментарием: «Гипотеза. Уточнить действия в случае неутверждения вакансии». Это не отход от текста, а ранний элемент анализа, повышающий зрелость модели.
Связь с последующими процессами
Утверждённый список вакансий -- выход процесса. В реальной цепочке за отбором следует оформление сотрудника на работу. Для такой стыковки используется объект «Процесс-интерфейс» (Process Interface). На диаграмме после события «Список вакансий утверждён» размещается интерфейс с названием «Оформление сотрудника на работу». Он обозначает переход к другому детализированному процессу, не раскрывая его внутреннюю структуру. Если информация о последующем процессе отсутствует, модель можно завершить финальным событием, оставив точку расширения на будущее.
Оформление и экспорт модели
Чтобы модель была понятна вне среды моделирования (например, в ARIS), на неё выводят максимум атрибутов: названия, авторство, дату создания. При копировании через Ctrl+A и вставке в Word модель превращается в растровое изображение -- все внутренние ссылки и атрибуты становятся неактивными, но остаются визуальными подсказками. Поэтому важно сразу закладывать в модель текстовые метки о прикреплённых документах.
Краткие итоги
Представленный материал выстраивает целостный взгляд на моделирование внутренних процессов организации и закладывает основы критического анализа исходных описаний. Отправной точкой служит чёткое разграничение процессов, нацеленных на внешнего потребителя, и тех, чьи границы полностью лежат внутри компании. Такое разделение определяет не только источники событий, но и характер управленческих воздействий: стратегические ориентиры и ключевые метрики «спускаются» с верхних уровней и конкретизируются в показателях экземпляров процесса, тогда как внешние взаимодействия требуют сквозной координации подразделений.
На примере отбора персонала показано, что методологически выверенное построение цепочки начинается с правильного позиционирования процесса в иерархии. Декомпозиция блока «Управление персоналом» до уровня «Отбор персонала» иллюстрирует принцип сохранения связности: управляющие воздействия верхнего уровня транслируются в детализированную модель через метрики и события, а внутренние входы, такие как подписанные заявки, несут в себе требования смежных структурных единиц.
Ключевая ценность изложенного подхода --- отношение к исходному текстовому регламенту не как к истине, а как к объекту анализа. Неполнота описания, например отсутствие вариантов решения при согласовании или утверждении, не игнорируется, а превращается в артефакты модели: примечания и гипотезы по ветвлению. Такой приём позволяет уже на стадии построения процесса «как есть» инициировать уточняющие вопросы, подсвечивать формальные процедуры и закладывать основу для будущих оптимизаций. Выделение цветом гипотетических веток делает видимыми зоны неопределённости и стимулирует владельца процесса предоставить недостающую логику.
Практическую пользу усиливает набор технических средств обогащения диаграммы. Атрибуты и ссылки на регламентирующие документы превращают плоскую картинку в многослойный информационный объект. Использование ролей вместо должностей обеспечивает гибкость: один и тот же функционал может выполняться разными исполнителями в разных экземплярах без размножения элементов модели. Объект «процесс-интерфейс» замыкает сквозную цепочку, не перегружая текущую диаграмму деталями последующих шагов, и чётко обозначает границы ответственности между процессами. В совокупности эти приёмы формируют у аналитика навык не просто графически фиксировать текстовые инструкции, а извлекать из них системные противоречия и проектировать точки будущего улучшения.
Место внутреннего процесса в иерархии
Процесс отбора персонала --- пример внутреннего процесса. В отличие от сквозных процессов, обслуживающих внешнего клиента (например, разработка проекта мебели), он не имеет входов извне организации. Все его входы и выходы исходят из внутренних подразделений.
Каждый детализированный процесс связан с процессами верхнего уровня. На карте верхнего уровня отбор персонала --- это детализация блока «Управление персоналом». Этот блок делят на группы (найм, обучение, отбор), так как изображать всё одной цепочкой неудобно и методически неверно.
Особенности моделирования внутреннего процесса
Главное --- в нём нет внешних клиентов. Входом служат «Заявки на персонал от начальников отделов». Это внутренний документ, имеющий статус «подписанные заявки», который отображается в атрибутах объекта. К заявке можно привязать линк на «Регламент подписания заявок», разместив ссылку прямо на модели.
При построении используются роли, а не должности. Например, роль «Ответственный за подбор персонала» в одном экземпляре процесса может выполняться начальником отдела, а в другом --- рядовым менеджером. Это даёт гибкость без перегрузки схемы конкретными должностями. При необходимости к роли можно привязать список должностей.
Построение цепочки операций и анализ текста
Модель строится точно по текстовому описанию «как есть». Последовательность шагов:
- Стартовое событие --- наступление 25-го числа последнего месяца квартала. Оно активирует функцию «Сбор заявок на персонал у начальников отделов».
- После сбора наступает событие «Заявки собраны».
- Функция «Обработка заявок» выдаёт проект списка вакансий и пояснительную записку. Если формат записки не описан, этот факт фиксируется как недостаток исходных данных.
- «Согласование материалов с начальником отдела». Текст говорит, что ответственный «согласовав подготовленные материалы со своим начальником, рассылает их трём заместителям». Никакого варианта несогласия не упомянуто. Это ошибка описания: любое согласование подразумевает принятие решения, а не формальное подписание. В модель добавляется примечание: «Не конкретизировано решение по согласованию вакансий. Уточнить».
- Далее материалы поступают на совещание. Роль участников --- заместители генерального директора. Методологически верно скопировать их должности из оргструктуры, но для учебных целей допустимо использовать обобщённую роль.
- Функция «Совещание» имеет на входе проект списка вакансий, пояснительную записку и предложения от одного из заместителей (этот вход пришёл из другого процесса). По итогам совещания исходный текст утверждает, что список вакансий всегда утверждается. Это снова формальность. Аналитик вводит гипотезу по ветвлению: добавляется выход «Список вакансий не утверждён», который выделяется другим цветом и сопровождается комментарием: «Гипотеза. Уточнить действия в случае неутверждения вакансии». Такой приём не искажает исходную модель, а подсвечивает зону неопределённости.
Связь с последующими процессами
Утверждённый список вакансий --- выход отбора персонала. За ним обычно следует оформление сотрудника на работу. Для стыковки применяется объект «Процесс-интерфейс». Он обозначает переход к другому детализированному процессу, не раскрывая его внутренности. Если о следующем процессе нет информации, модель можно завершить на событии «Список утверждён», оставив точку расширения.
Оформление и экспорт модели
Чтобы модель была информативной даже в виде картинки, на ней размещают текстовые атрибуты: названия присоединённых документов, статусы, имя автора. При копировании в Word все внутренние ссылки становятся неактивными, но по подписям можно понять, какие регламенты привязаны. Поэтому рекомендуется выводить максимум атрибутов и комментариев, а также идентифицировать исполнителя модели.
Ключевая идея
Уже на этапе создания модели «как есть» аналитик не просто перерисовывает текст, а выявляет его пробелы --- отсутствие развилок, формальные утверждения --- и оформляет их в виде примечаний и гипотез. Это закладывает фундамент для будущего уточнения и оптимизации процесса.
1. Внутренний процесс отличается от сквозного отсутствием внешних клиентов и замкнутостью входов/выходов внутри организации.
2. Любой детализированный процесс связан с верхним уровнем; стратегические метрики конкретизируются в операционных показателях.
3. При моделировании по тексту «как есть» аналитик обязан фиксировать обнаруженную неполноту описания примечаниями и гипотезами.
4. Отсутствие вариантов решения при согласовании или утверждении — симптом формальной процедуры, требующей уточнения.
5. Гипотезы по ветвлениям выделяются в модели цветом и снабжаются текстовым комментарием для последующих итераций.
6. В модели следует использовать роли, а не должности, так как в разных экземплярах процесса функцию могут выполнять разные сотрудники.
7. Атрибуты объектов (статусы документов, подписи) и ссылки на регламенты делают модель более информативной.
8. Объект «процесс-интерфейс» обеспечивает корректную стыковку текущей диаграммы со следующим процессом без детализации последнего.
9. Вход, приходящий из другого внутреннего процесса, не требует на текущей схеме отображения своего источника — достаточно обозначить его как внешний по отношению к модели.
10. При экспорте модели в виде картинки внутренние ссылки и атрибуты становятся неактивными, поэтому текстовая визуализация атрибутов обязательна.
11. Нецелесообразно рисовать всю цепочку верхнего уровня в одной модели — её разбивают на группы процессов для сохранения наглядности.
12. Уже на этапе создания модели «как есть» допустимо вносить аналитические пометки, что сокращает время последующего улучшения процесса.
1. Чем внутренний процесс организации принципиально отличается от сквозного, ориентированного на клиента?
2. Как определить место конкретного детализированного процесса в иерархии верхнего уровня?
3. Почему в моделировании внутреннего процесса предпочтительнее использовать роли, а не конкретные должности?
4. Какую информацию о входном документе можно отобразить с помощью атрибутов объекта?
5. Что такое гипотеза по ветвлению и в каком случае она добавляется в модель «как есть»?
6. Почему отсутствие в описании варианта неутверждения списка вакансий считается ошибкой?
7. Каким способом в модели отмечают, что решение по согласованию материалов не конкретизировано?
8. Для чего служит объект «процесс-интерфейс» и в какой момент он применяется?
9. Как отразить тот факт, что входная информация поступила из другого внутреннего процесса?
10. Какие риски возникают при экспорте модели в растровое изображение и как их минимизировать?
11. Почему процесс верхнего уровня не изображают одной длинной цепочкой, а делят на группы?
12. Какие действия аналитика позволяют уже на фазе описания «как есть» повысить зрелость будущей модели?
