Подборка полезных публикаций для веб-мастеров и заказчиков

Советы айтишника заказчику, или как нельзя автоматизировать бардак

28.01.2020 | habr.com

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

О целях и границах проекта



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

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


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

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

Совет: В процессе работы вспоминайте о границах проекта. Очень часто, проектируя информационную систему, хочется “автоматизировать и вот этот вид работы, и еще вот такой”. Старайтесь этого не допускать. Каждая новая функция — дополнительный объем работы для вас и подрядчиков.


 

О рабочей группе




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

Совет: Вот почему ранее я говорила про необходимость согласовать цели проекта с первым лицом компании. На этапе формирования рабочей группы коллеги могут сопротивляться будущим изменениям. Это нормально! Но надо быть к этому готовым. Например, при согласовании цели ИТ-проекта вы можете обсудить с руководством вопрос мотивации участников.


 

Формирование требований к автоматизированной системе




Как действовать, чтобы обсуждение задач автоматизации и функциональных требований прошло быстрее? Есть два подхода:
1. Если процессы, которые вы решили автоматизировать, достаточно типовые, вы можете привлечь к дискуссии профессионалов – ИТ-компанию, у которой есть опыт автоматизации сходных процессов. Они подскажут какие решаются задачи, какие процессы бывают затронуты и озвучат функциональные требования. А вы просто отредактируете такой список под себя.
2. Выделить из рабочей группы основного отраслевого эксперта, чья деятельность будет затрагиваться сильнее всего. И первый вариант задач и функциональных требований написать с ним вдвоем.

Главное – получить первый набросок задач и функций, и потом его уточнять, а не ждать, что рабочая группа сама его сформирует. Базовая истина — всегда легче критиковать, чем придумывать.
 

Следующий шаг – формирование технических требований


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

Когда мы прошли эти шаги – у нас, считайте, есть техническое задание на ИТ-проект!
 

Выбор подрядчика




Дальше наступает очередь организационного этапа: выбора компании-исполнителя работ. В современном мире такой процесс организуется как конкурсная процедура.
 

  • Если вы – государственная компания и информационная система создается из средств госбюджета – у вас есть 44 ФЗ. По сути, он регламентирует все правила проведения конкурсов.
  • Если вы – компания с государственным участием, то действуете на основании 223 ФЗ и собственного положения о закупках.
  • Наконец, если вы – частная компания, у вас есть положение о закупках.


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

Байка: одна компания (не могу называть) решила сделать информационный ресурс для всей страны. Это не государственная структура, и руководство не ограничило вилку доступных цен, желая получить как можно больше вариантов.
На конкурс пришло 75 компаний. Заказчик получил предложения по реализации своего ТЗ с разбросом цен от 3 млн руб до 300 млн руб. И не смог принять решение. Конкурс был отменен, задачи не решены.

Совет: планируя сроки реализации проекта, помните, что конкурсные процедуры, как правило, занимают около месяца.

Отступление о типах ИТ-проектов


Прежде чем говорить об особенностях реализации нашего ИТ-проекта, надо сделать небольшую паузу и оговорить, что ИТ-проекты на самом деле бывают разными. Какими?

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

Проекты внедрения программного продукта
ИТ-проект может быть про внедрение некоторого программного продукта. Причем как «горизонтального», так и специализированного. Под «горизонтальным продуктом» в мире ИТ понимают продукт, который без дополнительных настроек решает вполне конкретную задачу автоматизации конкретной функции, причем нужной всем пользователем. Прекрасный пример такого продукта – Microsoft Word. Мы же все понимаем, что и Word – информационная система? Но привыкли, что он устанавливается просто, и научиться этому легко. Это происходит как раз потому, что система решает узкую задачу: набор текста с форматированием, его сохранение и печать. И задача универсальна.
Специализированный программный продукт. Пример – бухгалтерская система. В таком продукте вроде бы и есть все нужные для ведения бухгалтерии функции… Но! У каждого предприятия свой план счетов, аналитика по счетам, участники процессов согласования и утверждения бухгалтерских документов… То есть требуется настройка программного продукта под ваш бизнес.

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

Совет: Хочу обратить внимание, что, даже при необходимости закупки в вашей организации принтеров, я настоятельно советую формировать техническое задание примерно так, как я рассказывала ранее. Это источник экономии ваших средств. Поскольку, начав разбираться, почему же не хватает принтеров, может выясниться, что у вас много сетевых принтеров, которые почему-то используются как «лично чьи-то», и надо не покупать оборудование, а достаточно поменять настройки. Это выйдет намного дешевле. Думаю, все со мной согласятся.


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

Реализация проекта. Работа заказчика




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

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

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

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

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


 

Об управлении разработкой информационной системы


Те, кто сталкивался с ИТ-системами, наверняка слышал термины “каскадная” (или “водопадная”) разработка и agile. Расскажу чуть подробнее, в чем разница. Традиционно в мире ИТ стандартизация подхода к разработке привела к каскадной методике создания ИТ-решений. Ведь, согласитесь, любая стандартизация преследует одну цель: кто бы что-то ни делал – результат будет ровно как планировали. Каскадный подход такое вполне обеспечивает. Его суть в трех словах: сначала мы все спроектируем, опишем в документах, а потом напишем программный код, сверим, как он работает с документами технического задания и технического проекта – и вот! Что хотели – то и получили. Казалось бы, удобно работать всем участникам проекта, и исполнителю, и заказчику. Проблема только одна: время. Пока мы все проектировали – изменился мир, появились новые виды деятельности в вашем бизнесе, изменилось штатное расписание, перераспределились зоны ответственности. И система в старом виде теперь не очень и нужна.
Что такое Agile (или Scram)? Это методика создания ИТ-системы «маленькими кусочками», когда мы задачу разбиваем на подзадачи, которые можно разработать и тестировать за две недели – месяц. Такова задумка. В чем подвох? В том, чтобы задачу поделить на «самостоятельные кусочки». Увы, так не получается почти никогда.

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


 

Организация работы на стороне заказчика, несколько советов


1. Прежде, чем начинать «автоматизацию всего», нужно выделить высокоприоритетные задачи (набор процессов, где отсутствие автоматизации мешает жить).

2. Обсудите внутри компании, как эти автоматизированные процессы будут обмениваться информацией со смежными процессами деятельности.

Поясню. Вы решили автоматизировать документооборот, с коллегами поняли, что теряются входящие письма от управляющей организации. Принимаете решение — автоматизировать не весь документооборот, а только регистрацию входящих. При этом вы должны решить, если входящие будут регистрироваться электронно, а исходящие – нет, вас это устроит? И как это будет работать? Если ответили на эти вопросы – смело делаем проект по автоматизации процесса регистрации входящих писем. Такой шаг называется «Определение функциональных границ проекта». После него вы сможете также конкретно определить участников, то есть организационные границы проекта, и сделать проект обозримым. Для него можно будет применить хоть каскадный метод, хоть agile.

3. Если такой небольшой участок автоматизации нельзя выделить, попробуйте такой подход: найдите подрядчика на этапе написания ТЗ, и закажите ему не только ТЗ, но и разработку простых макетов на наиболее важные части системы.

Помните: важно обеспечить к проекту интерес руководства. Покажите ему макеты аналитических панелей: когда они научатся получать все данные для этих понятных панелей, будет удобнее принимать решения. Это поможет сэкономить годы работы и миллионы рублей.


Макетные образцы, кстати, прекрасно создавать по методике Agile. Можно все быстро решить, сделать, показать и, при необходимости скорректировать ожидания. На самом деле Agile возникла как методика быстрого прототипирования, а вовсе не для создания промышленных стабильно работающих ИТ-систем.

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

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

Помните, что подрядчик может поменяться, а если система не задокументирована – новый подрядчик начнет работу с нуля!


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

Наверное, вы уже хотите задать вопрос: “Господи, сколько же займет времени и денег проект?”. Об этом в конце материала.

Сейчас же я хочу еще поговорить о последних двух этапах жизненного цикла ИТ-проекта: внедрении и эксплуатации.
 

Организация процесса внедрения




Итак, совместная с исполнителем рабочая группа по управлению проектом приняла систему. Куда приняла и что делать дальше?

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

Заметьте, старые методы исполнения их обязанностей еще действуют. То есть участники опытной эксплуатации делают двойную работу! Не забывайте их мотивировать!


Цель этапа опытной эксплуатации – убедиться, что работать в системе возможно. Она не выдает неожиданных результатов и ошибок, ей достаточно удобно пользоваться. Если есть ошибки, неудобства, что-то еще «не то», их фиксируют в «Журнале опытной эксплуатации». Исполнитель должен устранить замечания.

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


После опытной эксплуатации появятся сотрудники, умеющие работать в ИТ-системе. Они смогут помогать коллегам освоить новый способ повседневной работы. Опытная эксплуатация обычно длится от 1 до 3 месяцев.

После исправления выявленных недочетов исполнителем, система принимается в промышленную эксплуатацию и становится боевым решением для ведения бизнеса. Акт приемки в промышленную эксплуатацию формально завершает ИТ-проект.
 

Два слова про обучение персонала


Мы помним, что часть сотрудников (участники опытной эксплуатации) уже прошла обучение, которое организовал подрядчик. Что делать с остальными сотрудникам? Их надо учить. Можно к этой работе привлечь как уже обученных специалистов, так и подрядчика. Оба варианта приемлемы. Просто помните, что процесс обучения всегда «платный». Или вы в явной форме оплатите эти услуги подрядчику, или придется отвлекать ваш персонал от основной работы на обучение коллег.

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

Еще один организационный момент, который важно помнить при приемке системы в промышленную эксплуатацию. Акт – актом, но важно продумать процесс перехода к работе в новой системе. Пример:
 

  1. Вы определяете дату, с которой ВСЕ операции выполняются в новой системе. Увы, люди не совершенны. Поэтому советую не только назначить дату, но и предусмотреть мотивирующий инструмент.
  2. Как правило, такая дата не «завтра после подписания акта», а через какой-то срок, обычно называемый переходным периодом. В этот период организация живет в двух мирах: старом и новом. По сути переходный период как бы расширенная опытная эксплуатация, только уже со всеми пользователями.

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


Расскажу старый, но действенный пример мотивации к внедрению. Создавалась система управления деятельностью отдела продаж. На этапе внедрения, сотрудники не хотели ею пользоваться и продолжали выставлять все счета в ручном режиме. Директор компании выпустил внутренний приказ: счета, выставленные и оплаченные вне системы, не будут учитываться при расчете премии продавца. Система внедрилась за 3 (!) дня! Да, эти три дня были адом для исполнителя, вылез миллион недочетов. Но, хотя, казалось бы я «представитель исполнителя», очень советую подумать о таких способах мотивации.

Разговор об организации процесса эксплуатации системы оставлю на следующий раз. Но отмечу, что сопровождение системы после внедрения тоже требует договора, лучше с разработчиком. Это отдельный тип договора, который должен определить способы обращения к разработчику, при обнаружении ошибок, и правила поведения с разработчиком, если поменялся какой-либо процесс (или появился новый). То есть договор прописывает, как исправить ошибки и как вы вместе планируете развивать систему. Такой тип договора называется SLA (Service Level Agreement). Подчеркну, что это отдельный договор.
 

Несколько слов о стоимости и сроках




В ИТ используется универсальный подход к определению стоимости работ, так называемый ресурсный метод. Оценивается какая команда специалистов, в какой срок реализует требуемый набор функций. Стандартный состав команды: на автоматизацию одного процесса (например, процесса управления деятельностью АХО) нужна команда из 1 руководителя проекта, 1 бизнес-аналитика, 1 системного аналитика, 2-3 разработчиков, 1 тестировщика и «половины» технического писателя. Понадобится не менее 3 месяцев. Дальше определяется ставка (рыночная, например) специалистов. Получается стоимость одного процесса. К чему я это? Планируя процесс создания ИТ-системы, вы можете прикинуть его стоимость. Для грубой оценки рекомендую посмотреть зарплаты специалистов на hh. Точный расчет конечно изменится, поскольку конкретный исполнитель будет учитывать сложность процессов, возможность использования имеющихся у него уже разработанных компонентов, но…
Помните: никакой исполнитель не сможет на первой встрече ответить сколько стоит система, пока ему не сказали, какие процессы надо автоматизировать. Он может только грубо оценить. Как и вы сами.



Если вы усвоили рецепт ИТ-проекта, то результаты поразят вас.
Всем спасибо!

сохранить ссылку