BoatmansHome: АвтоматизированныеСистемы/КакЗаказатьАвтоматизацию ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

Как заказать автоматизацию


Эта статья предназначена для заказчиков ИТ проектов.
Для менеджеров и сотрудников, которые хотят автоматизировать свою работу и вынашивают мысль обратиться со своей нуждой в собственный отдел автоматизации, к интегратору, разработчику заказных систем или к начальству с просьбой о закупке программного обеспечения.
Для представителей заказчика уже идущего ИТ проекта, в том числе для менеджеров проекта со стороны заказчика.
Для инвесторов и предпринимателей, которые хотят вложить деньги в ИТ разработку чтобы получить ИТ сервис.
Для менеджеров и бизнес-аналитиков, участвующих в инициации ИТ проекта, одной из задач которой – заложить (и выбить) бюджет на создание системы.
В общем, для всех, кто рано или поздно приходит к автоматизаторам заказывать ИТ проект: поставку ПО и железа, внедрение и интеграцию, заказную разработку.


Так же это полезно для менеджеров и аналитиков ИТ проектов, которые могут повлиять на выстраивание отношений с заказчиком в ходе проекта. Хотя они и могут обнаружить, что частично здесь повторяются мои предыдущие заметки.


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


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


Линейка ГОСТов серии 34 была шагом в верном направлении, однако уже сейчас понятно, что туда надо кое-что добавить.
Практика показывает, что недостаточно простого понимания структуры автоматизированной системы и иерархии продуктов поставки ИТ проекта, недостаточно понимания порядка проектирования ИТ системы с ее первых стадий.
Необходимо понимание полного жизненного цикла ИТ системы/продукта, включая вопросы бюджетирования, выбора покупных компонентов и назначения субъектов на роли.

Проблемы


Посмотрим чуть более подробно, конфликтные линии на старте любого ИТ проекта.


Первое, с чем надо определиться – это какая польза будет нанесена.
Некоторые пользователи (или другие заинтересованные лица) жаждут автоматизации для решения своих рабочих проблем, но другие пользователи или заинтересованные лица справедливо опасаются вопросов заказчика, который выделяет деньги: «чью работу мы сможем рассматривать под лупой, кого мы сможем уволить, кого мы сможем догрузить, кто пообещает мне лучше работать и, наконец, сколько мы сэкономим/заработаем?».


Второй, казалось бы, невинный вопрос: «сколько мы должны потратить на создание ИТ системы?»


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


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


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


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


Заказчик, который еще не знает, будем ли мы делать эту систему, тоже не склонен оплачивать аналитические работы. Кроме прочего он часто уверен, что скорее всего получит толстую бесполезную пачку бумаги, в которой все равно ничего не поймет (причем, никто ничего не поймет). К сожалению такое впечатление создает современная практика консалтинга в целом (не только ИТ консалтинга).


Очень быстро наступает разработка и тот же менеджер начинает бегать с выпученными глазами и воплями, что у него команда из 20ти разработчиков уже неделю не может приступить к работе без требований.
А заказчик готовит комиссию из злобных желчных приемщиков для организации приемо-сдаточных испытаний, с мыслью: «там и сочтемся».


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


Пятая проблема вытекает из предыдущих.


В итоге заказчик встает перед взвешиванием затрат и выгод с примерно такими исходными данными:


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


В строительстве и машиностроении все уже смирились, что без проектирования нельзя. А в ИТ пока еще продолжают изобретать орг-управленческие и технологические велосипеды в надежде, что в этот раз удастся срезать угол. Расхожая мировая статистика показывает, что пока чаще не удается.

Иерархия предметов поставки ИТ проекта


Давайте посмотрим, какие существуют варианты предметов поставки ИТ проекта и как они друг с другом соотносятся.


1. На самом нижнем уровне иерархии находится программа, программный продукт, программный комплекс, программная система – это то, что поставляется на дисках или скачивается из интернета и само по себе не приносит никакой пользы.
2. После объединения программы с оборудованием мы получаем информационную систему, способную вводить, хранить, перерабатывать и выводить данные. Информационные системы индивидуального пользования часто называются АРМ (автоматизированное рабочее место).
3. После добавления к информационной системе людей и/или подключения к смежным системам мы получаем автоматизированую систему. Автоматизированные системы еще могут называться ИТ сервисами.


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


На любой предмет поставки ИТ проекта справедлив взгляд, как на актив, с финансовой точки зрения.
На любой предмет поставки ИТ проекта справедлив взгляд через призму бизнес-модели или бизнес-плана.


В зависимости от назначения и условий создания мы можем получать разные классы ИТ продуктов/систем у которых будут свои собственные особенности жизненного цикла.


Вот лишь некоторые параметры, влияющие на жизненный цикл системы:


В свое время в ГОСТ серии 34 был относительно хорошо описан жизненный цикл автоматизированной системы для случаев создания автоматизированной системы/сервиса, с заказчиком в виде юрлица, с режимом создания системы – заказная разработка.
С небольшими допущениями серия ГОСТ 34 подходит для внутренней разработки.
Для других случаев идеология ГОСТ 34 продолжает действовать, но жизненный цикл приходится выстраивать по другому.

Жизненный цикл автоматизированной системы

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


Роли (организации, структуры или персоны – пока не важно):


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


Вот вариант проработки методологии проектирования АС – первые 4 стадии ее жизненного цикла.


file:asps1.png


file:asps2.png


file:asps3.png


file:asps4.png


На диаграммах показаны участки работы для нескольких сценариев:
1. На конкурс выставляется ТТЗ (тактико-техническое задание), на основе которого ищется интегратор/разработчик, который создает информационную систему под ключ или пишет/поставляет/кастомизирует/интегрирует все ПО и разворачивает его на оборудовании Заказчика. Тогда интеграторы готовят свои варианты концепции системы и приходят на конкурс со своими ценами и сроками. Процессы помечены (*). Этот вариант можно применять при небольших и/или типовых системах, в которых на уровне ТТЗ уже достаточно хорошо снижена неопределенность.
2. На конкурс выставляется предварительное техническое задание по итогам концептуальной проработки системы, предметом конкурса могут быть лоты по отдельным работам/подсистемам или информационная система в целом. процессы помечены (***). Этот вариант применяется для больших и/или нетиповых систем с разнобразной интеграцией. Тогда для снижения неопределенност до приемлемого уровня требуется концептуальное проектирование.
3. На конкурс ничего не выставляется. Или делаем сами для себя или выбираем приглянувшихся поставщиков/вендоров/подрядчиков без конкурса. В принципе в таких случаях немного снижается накал конкурсных страстей и иногда появляется шанс спокойно проектировать систему на ранних стадиях.
4. Для предварительного определения стоимости системы могут проводиться запросы котировок среди вендоров/поставщиков/подрядчиков. Процессы помечены (**).


Назначения и совмещения ролей

Что можно сказать о хороших и плохих назначениях ролей, их совмещении и разделении.
1. Генподрядчик и Генпроектировщик должны быть тесно связаны с Заказчиком и Владельцем объекта автоматизации, так как они в конечном итоге должны продемонстрировать достижение целей автоматизации, то есть улучшение рабочих процессов пользователей. Иными словами, они играют на стороне Заказчика или хотя бы не против него. Варианты

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


2. Архитектор ИС, вендоры, поставщики, подрядчики.

Единственное, что важно здесь повторить – они не должны и не будут брать ответственность за АС в целом, то есть не надо их ставить на роли Генпроектировщика и/или Генподрядчика.


К сожаланию, практика часто склоняет к плохому совмещению ролей.
Явное выделение роли Генпроектировщика и Генподрядчика ставят вопросы источника и объема финансирования их деятельности на ранних стадиях проекта при создании тактико-технического задания и концепции системы. Если эти роли явно не выделять, то иногда создается иллюзия, что проектирование АС на предпроектных стадиях как бы ничего и не стоит.


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


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


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


Отдача ИТ проектов

Можно пройти по процессу и посмотреть, как может нарастать ком проблем в ходе проектирования системы.
1. Все начинается с желания сэкономить, и/или низкой экспертизе, и/или непреодоленном конфликте интересов при выполнении самых первых работ там, где происходит обоснование необходимости создания АС. Плохо обоснованная необходимость создает сразу два негативных фактора:

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

3. Попытка выставить получившееся ТТЗ на запрос котировок приводит к тому, что

4. Концептуальное проектирование из такой исходной позиции не приносит облегчения:

Поскольку мы договорились, что в нашем сценарии заказчик не знает пределов стоимости системы и не может определить пределы стоимости концептуального проектирования, даже при заказе концепции она часто недоснабжается ресурсами. Иногда интегратор дофинансирует концептуальное проектирование, но, естественно, делает это в своих интересах с соответствующими последствиями.
5. В итоге все, что у нас получилось, а получились у нас раздутый нечеткий объем, размытые границы, оценки с перезакладом, неясная отдача. Так вот, это поступает заказчику к принятию решения. Заказчик чувствует, что в оценках есть перезеклад, а предыдущий опыт показывает, что сделано все равно будет не все, что обещано. В итоге начинается подбор делителя для сроков и бюджета.
6. Если необходим конкурс расплывчатое техническое задание с урезанным бюджетом и сроками выходит на конкурс. И иногда еще приходят какие-то фрики, которые все не так поняли и, демпингуя, выигрывают контракт.
7. Кто бы ни получил контракт, дальше подтягивается основная проектная команда, получает на вход размытые проектные решения и пытается что-то построить. Иногда после нескольких переделок и урезки объема удается построить полезную автоматизированную систему, иногда нет. В итоге собранная мной статистика успешного запуска автоматизированных систем с нуля (не замены технических средств под теми же процессами) плачевна. Шансы проекта построения АС с нуля за одну попытку – 15–30%. Там, где необходимость автоматизации остра, заказчик пробует раз за разом и со второй или третьей попытки у него что-то получается.


Таким образом отдача ИТ проектов в области построения автоматизированных систем для бизнеса может быть улучшена в разы.


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


 
Много файлов (4).[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]