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

главная

внедрение BPM-систем

консультирование

мои статьи

обо мне & галерея проектов

контакты

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

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

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

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

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

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

Концепция

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

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

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

Регламент

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

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

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

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

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

 

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

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

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

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

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

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

Контакты

город Москва

e-mail: anton@kholodkov.ru

skype: a_kholodkov

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

Распространенность технических заданий обусловлена «философской» природой этого документа. Техническое задание – это формальное описание того, что нужно Заказчику и что, соответственно, он ожидает получить от Исполнителя.

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

Не погружаясь в детали разработки ТЗ, хочется акцентировать внимание на том, в каких случаях в создании ТЗ может быть полезен ИТ-консультант. Классических сценариев всего два: 1). ТЗ пишет Заказчик и 2). ТЗ пишет Исполнитель.

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

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

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

Например, выступая на стороне Заказчика, Консультант может быть полезен, если:

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

Выступая на стороне Исполнителя, Консультант может быть полезен, например, в следующих случаях:

  • Отсутствие или нехватка ресурсов для разработки ТЗ требуемой квалификации.
  • Необходимость абстрагироваться при составлении ТЗ от используемых Исполнителем методик, технологий, платформ и сконцентрироваться на потребностях Заказчика.

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