ИТ-консультант.рф | Холодков Антон

аналитик, архитектор, команда разработки для реализации Ваших идей

поделиться ссылкой:

Главная

Услуги

Решения

Примеры работ

Галерея проектов

Мои статьи

Договоры и цены

Обо мне

Контакты

Вакансии

Текущий статус:

Ищу интересные проекты :)

Подробнее

Я:

в LinkedIn

на free-lance.ru

в ЖЖ

in english

Оказываемые услуги

Регламент

Об ИТ-консалтинге

Бизнес-аналитика

Системная аналитика

Разработка IT-стратегии

Участие в конкурсах

Заказная разработка ПО

Разрабатываемые документы

Аналитическая записка

ИТ-стратегия

Конкурсная документация

Концепция

Описание бизнес-процесса

Регламент

Техническое задание

Технический проект

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

Регламент может описывать как бизнес-процесс в целом, так и какую-либо его часть. Например, «Регламент работы в информационной системе Х в рамках процесса Y» формализует такой важный аспект процесса Y, как сценарий использования в нем системы X.

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

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

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

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

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

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

Примеры регламентов из моих работ:

Проект порядка использования портала regulation.gov.ru

Проект порядка регистрации пользователей на портале regulation.gov.ru

© Холодков Антон, 2000-2017. Буду рад использованию материалов этого сайта, но не забывайте ставить ссылку на него.