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

Новая статья:

BPM-система в действии или как сделать много за мало

Прочитать...

Артефакты ИТ-консалтинга

Регламент

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

Концепция

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

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

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

Регламент

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

Артефакт (от лат. Artefactum — искусственно сделанное) — явление, процесс, предмет, свойство предмета или процесса, появление которого в наблюдаемых условиях по естественным причинам невозможно или маловероятно. Появление артефакта, следовательно, является признаком целенаправленного вмешательства в наблюдаемый процесс, либо наличия неких неучтённых факторов.

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

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

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

Подробнее об ИТ-консалтинге

Зачем это нужно?

Для кого это может быть интересно?

Как улучшить достижение бизнес-целей за счет использования ИТ?

Что именно делается для этого?

В каких случаях целесообразно участие консультанта?

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

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

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

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

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

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

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

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

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