Советы It-Специалиста Заказчику, Или Как Не Автоматизировать Бардак

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



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



Советы IT-специалиста заказчику, или как не автоматизировать бардак

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

В конечном счете, ИТ – это не что иное, как технология со своими возможностями.

Но создание информационной системы не может быть самоцелью.

Цель должна быть сформулирована с точки зрения вашего бизнеса.

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

Лучше привлечь внимание руководства к проекту как можно раньше.

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

Автоматизация – это всегда процесс изменения процессов деятельности.

Наверняка каждый слышал крылатую фразу «беспорядок не автоматизируешь».

И это действительно так.

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

Правда, в результате вы получите более четкие правила работы и предсказуемые результаты бизнеса.

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

Совет: Во время работы помните о границах проекта.

Очень часто при проектировании информационной системы хочется «автоматизировать и тот вид работы, и этот».

Постарайтесь не допустить этого.

Каждая новая функция — это дополнительный объем работы для вас и подрядчиков.



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



Советы IT-специалиста заказчику, или как не автоматизировать бардак

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

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

Совет: Именно поэтому ранее я говорил о необходимости согласовывать цели проекта с первым человеком компании.

На этапе формирования рабочей группы коллеги могут сопротивляться будущим изменениям.

Это отлично! Но мы должны быть к этому готовы.

Например, согласовывая цель ИТ-проекта, вы можете обсудить с руководством вопрос мотивации участников.



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



Советы IT-специалиста заказчику, или как не автоматизировать бардак

Как ускорить обсуждение задач автоматизации и функциональных требований? Есть два подхода: 1. Если процессы, которые вы решили автоматизировать, достаточно типовые, к обсуждению можно привлечь профессионалов — ИТ-компанию, имеющую опыт автоматизации подобных процессов.

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

И вы можете просто отредактировать такой список под свои нужды.

2. Выбрать из рабочей группы главного отраслевого эксперта, деятельность которого будет затронута больше всего.

И вместе с ним написать первый вариант задач и функциональных требований.

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

Основная истина заключается в том, что критиковать всегда легче, чем изобретать.



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

Здесь требуется ИТ-директор компании.

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

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

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

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



Советы IT-специалиста заказчику, или как не автоматизировать бардак

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

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

    Фактически, он регламентирует все правила проведения соревнований.

  • Если вы компания с государственным участием, то вы действуете на основании 223 ФЗ и собственных правил закупок.

  • Наконец, если вы частная компания, у вас есть правила закупок.

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

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

Или появится компания, которая решит, что ей не важно ничего делать, а только получить контракт. Сказка: одна компания (не могу ее назвать) решила создать информационный ресурс для всей страны.

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

В конкурсе приняли участие 75 компаний.

Заказчику поступили предложения по реализации его технического задания стоимостью от 3 млн рублей до 300 млн рублей.

И я не мог принять решение.

Конкурс отменили, задачи не решили.

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



Экскурс по типам ИТ-проектов

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

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

То, что в просторечии называется «купим серверы и принтеры».

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

Причём как «горизонтальные», так и специализированные.

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

Отличным примером такого продукта является Microsoft Word. Мы все понимаем, что Word — это информационная система, верно? Но мы привыкли к тому, что его легко установить и легко освоить.

Происходит это именно потому, что система решает узкую задачу: набрать текст с форматированием, сохранить его и распечатать.

И задача универсальная.

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

Вроде бы в таком продукте есть все необходимые для бухгалтерского учета функции.

Но! На каждом предприятии есть свой план счетов, аналитика счетов, участники процессов согласования и утверждения учетных документов.

То есть программный продукт необходимо кастомизировать под свой бизнес.

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

И далее мы поговорим конкретно об особенностях управления проектом такого типа.

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

Это источник экономии ваших денег.

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

Это выйдет гораздо дешевле.

Я думаю, все со мной согласятся.

Примечание о сложности проекта или больших информационных системах.

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

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



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

Работа клиента



Советы IT-специалиста заказчику, или как не автоматизировать бардак

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

Конкурс проведен, и у вас есть подрядчик на IT-проект. Начинается этап реализации.

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

Только теперь в него войдут представители исполнителя.

Если исполнитель профессионал, он знает, что проект должен начинаться с общего собрания всех участников и согласования.

Устав проекта .

И это действительно так.

Именно Устав проекта позволяет прописать правила взаимодействия команд подрядчика и заказчика.

В техническом задании и договоре, в отличие от Устава, обычно нет таких подробностей, как имена ответственных за вполне конкретные проектные решения.

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

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

Компания-партнер по разработке системы не всегда понимает ваш бизнес.

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



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

Те, кто сталкивался с ИТ-системами, вероятно, слышали термины «водопадная» (или «водопадная») разработка и agile .

Расскажу немного подробнее, в чем разница.

Традиционно в мире ИТ стандартизация подхода к разработке привела к каскадной методологии создания ИТ-решений.

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

Каскадный подход это полностью обеспечивает. Суть его в трех словах: сначала мы все спроектируем, опишем в документах, а потом напишем программный код, проверим, как оно работает, с техническим заданием и техническим проектом – и вуаля! Мы получили то, что хотели.

Казалось бы, это будет удобно всем участникам проекта, и подрядчику, и заказчику.

Есть только одна проблема: время.

Пока мы все проектировали, мир изменился, в вашем бизнесе появились новые виды деятельности, изменилось штатное расписание, перераспределились зоны ответственности.

И система в старом виде уже не особо нужна.

Что такое Agile (или Scram)? Это методика создания ИТ-системы «маленькими кусочками», когда мы разбиваем задачу на подзадачи, которые можно разработать и протестировать за две недели-месяц.

Это идея.

В чем подвох? Суть в том, чтобы разделить задачу на «независимые части».

Увы, такого почти никогда не происходит.

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

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



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

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

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

Позволь мне объяснить.

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

Вы решаете не автоматизировать весь документооборот, а только регистрацию входящих.

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

Этот шаг называется «Определение функциональных границ проекта» .

После него также можно конкретно определить участников, то есть организационные границы проекта, и сделать проект видимым.

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

Помните: важно обеспечить заинтересованность руководства в проекте.

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

Это поможет сэкономить годы работы и миллионы рублей.

Кстати, создавать прототипы по методу Agile — это здорово.

Можно быстро решить, сделать, показать и при необходимости скорректировать ожидания.

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

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

Это группа ваших (это обязательно) сотрудников, которые будут следить за созданием, использованием, изменением и появлением новых продуктов на рынке, то есть будут нести ответственность за целостность и единую идеологию.

Обычно комитет возглавляет ИТ-директор, но в его состав также должны входить отраслевые эксперты.

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

Сделать эту часть требований оптимальной с точки зрения дальнейшего использования.

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

Вы с подрядчиком обсуждаете документы, конкретные проектные решения и промежуточные результаты.

Это важно понять.

Если вы этого не сделаете, подрядчик будет автоматизировать свои представления о вашем бизнесе, а не сам бизнес.

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

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



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



Советы IT-специалиста заказчику, или как не автоматизировать бардак

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

Где вы его приняли и что делать дальше? Традиционно первое принятие означает начало пробная эксплуатация .

Часто этому этапу уделяется мало внимания.

И он важен.

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

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

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

Если есть ошибки, неудобства или что-то еще «не совсем то», это фиксируется в «Журнале тестовой эксплуатации».

Подрядчик обязан устранить замечания.

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

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

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

Они смогут помогать коллегам каждый день осваивать новый способ работы.

Опытная эксплуатация обычно длится от 1 до 3 месяцев.

После устранения подрядчиком выявленных недостатков система принимается в эксплуатацию.

промышленная эксплуатация и становится боевым решением для ведения бизнеса.

Акт приемки в коммерческую эксплуатацию формально завершает ИТ-проект.

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

Мы помним, что часть сотрудников (участников опытной эксплуатации) уже прошла обучение, организованное подрядчиком.

Что делать с остальными сотрудниками? Их нужно учить.

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

Оба варианта приемлемы.

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

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

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

Поступок поступком, но важно продумать процесс перехода к работе в новой системе.

Пример:

  1. Вы определяете дату, с которой ВСЕ операции выполняются в новой системе.

    Увы, люди не идеальны.

    Поэтому советую не только назначить дату, но и предоставить мотивирующий инструмент.

  2. Как правило, такая дата приходится не «завтра после подписания акта», а через какой-то период, обычно называемый переходным периодом.

    В этот период организация живет в двух мирах: старом и новом.

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

Совет и история: Поскольку люди склонны сопротивляться новому, имейте в виду, что сотрудники будут недовольны новой системой.

Они скажут, что ничего не понятно и все медленно, что они сами бы еще час назад все сделали.

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

Расскажу старый, но эффективный пример мотивации к реализации.

Создана система управления деятельностью отдела продаж.

На этапе внедрения сотрудники не захотели им пользоваться и продолжали выставлять все счета вручную.

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

Система была внедрена за 3 (!) дня! Да, эти три дня были адом для исполнителя; выявился миллион недостатков.

Но, хотя, казалось бы, я «представитель исполнителя», я настоятельно советую вам задуматься о таких методах мотивации.

Обсуждение организации процесса эксплуатации системы я оставлю на следующий раз.

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

Это отдельный вид соглашения, в котором должно быть определено, как обращаться к разработчику в случае обнаружения ошибок, а также правила поведения с разработчиком, если какой-либо процесс изменился (или появился новый).

То есть в договоре указано, как исправлять ошибки и как вы планируете вместе развивать систему.

Этот тип соглашения называется SLA (Соглашение об уровне обслуживания).

Подчеркну, это отдельное соглашение.



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



Советы IT-специалиста заказчику, или как не автоматизировать бардак

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

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

технический писатель.

Это займет минимум 3 месяца.

Далее определяется ставка (рыночная ставка, например) специалистов.

Это приводит к стоимости одного процесса.

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

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

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

Помните: ни один руководитель не сможет ответить на первой встрече, сколько стоит система, пока ему не расскажут, какие процессы необходимо автоматизировать.

Он может сделать лишь приблизительную оценку.

Прямо как ты.



Советы IT-специалиста заказчику, или как не автоматизировать бардак

Если вы усвоили рецепт ИТ-проекта, результаты вас поразят. Спасибо всем! Теги: #Управление проектами #Управление персоналом #Бизнес-модели #управление командой #бизнес-процессы #техническое задание

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.