Требования — это основа основ хорошей IT-инфраструктуры. Именно они необходимы, чтобы составить ТЗ для подрядчика. От того, насколько точно и хорошо они сформированы, зависит бюджет, сроки и ваше удовлетворение от конечного результата. О том, как написать требования, из которых потом получится четкое ТЗ, рассказываем в этой статье.
628 просмотров
Что из себя представляют требования к ИТ-инфраструктуре?
По сути — это перечень самой важной информации о проекте. У требований нет какой-то четкой, устоявшейся формы. Это может быть и подробный документ с тщательным описанием даже второстепенных пунктов, длинное сообщение в мессенджере или письмо в электронной почте. И даже аудиосообщение, надиктованное на бегу или за рулем.
Так что форма не особо-то и важна. Главное, чтобы то, как составлены требования, удовлетворяло всех участников процесса.
Что обязательно должно быть в них?
В требованиях важнее всего наполнение, ведь в них есть такие пункты, без которых попросту нельзя написать нормальное ТЗ. Чтобы составить их правильно, достаточно задать себе несколько вопросов.
13/48 — Что такое требования к ПО? Курс Бизнес-анализ в IT.
Что будет, если составить требования некорректно?
От этого точно пострадают дедлайн и бюджет — сроки и затраты увеличатся. И, в некоторых, очень редких случаях, ухудшится качество конечного результата.
Кто составляет требования?
Составить требования можно двумя способами: самостоятельно, перед тем, как обратиться к потенциальному подрядчику и вместе с ним.
В первом случае требования составляет менеджмент вместе со штатными DevOps-специалистами и разработчиками. Почему менеджмент, а не одни инженеры? Любые работы с инфраструктурой решают некую бизнес-задачу. Например, оптимизацию ресурсов за счет масштабирования только высоконагруженных компонентов. Для её понимания и четкой формулировки необходимо, чтобы управленцы взаимодействовали с технарями.
Во втором со специалистами аутсорсера составляет требования технический директор, проджект-менеджер, ответственный за работы с системой, и специалисты с глубоким пониманием инфраструктуры.
Почему они могут быть составлен некорректно и как этого избежать?
Самая частая причина — заказчик упустил какой-то важный пункт или умолчал о чем-то.
Например, в одном из проектов клиент не предупредил, что ему недостает компетенций в построении процессов CI/CD и не рассказал, что в штате нет специалиста, который смог бы написать пайплайны для внутренних сервисов. Мы выяснили это уже после начала работ, которые пришлось приостановить, чтобы проконсультировать заказчика. Это увеличило сроки и затраты на проект.
В другом антикейсе заказчик не сформулировал четкий дедлайн (а он был). И несмотря на то что технические требования были расписаны очень подробно, сроки соблюсти не удалось.
Избежать подобных упущений поможет самопроверка и вопросы из нашей таблички выше.
Как выглядят идеальные требования к инфраструктуре?
Вот два примера хорошо сформированных требований, из которых потом получилось прекрасное ТЗ.
Лекция «Business Analysis: учимся понимать бизнес требования» Кирилл Белявский | APOLLO IT School
Первый — требования для переезда в новую инфраструктуру для увеличения пропускной способности системы.
Источник: vc.ru
Требования бизнеса к ИТ (выявление требований к ИТ, исходя из приоритетов бизнеса)
На этой странице рассмотрена методика «Требования бизнеса к ИТ», которая является одной из 9 методик улучшения ИТ. Все эти методики разработаны для планирования развития ИТ на год и более, в том числе в рамках разработки ИТ-стратегии.
На этой странице предложены 9 методик улучшения ИТ, которые можно использовать при планировании развития ИТ на год и более, в том числе в рамках разработки ИТ-стратегии.
 |  |  |  |  |  |  |
 | ||||||
 | ||||||
 | ||||||
 | ||||||
Методики, рассматриваемые на этом сайте :
 |  |  |  |  |  |  |  |  |
Краткое описание методики выявления т ребований бизнеса к ИТ
Методика «Требования бизнеса к ИТ» включает в себя: в ыявление требований бизнеса к ИТ, включая следующие группы требований:
- требования по поддержке целей (приоритетов) бизнеса;
- требования по снижению рисков и повышению безопасности ИТ;
- требования по затратам на ИТ и численности ИТ;
- требования по управляемости ИТ.
Также могут быть разработаны цели ИТ и проекты по ИТ, поддерживающие требования бизнеса к ИТ.
Пример требований бизнеса к ИТ:
Выявление требований бизнеса к ИТ уместно, если:
- Надо согласовать развитие ИТ с бизнесом;
- Надо в письменном виде зафиксировать, что бизнес-руководство ждет от ИТ, иначе успехов потом не вспомнят, а за не достижение нереальных (и быстроменяющихся) «хотелок» многочисленных бизнес-менеджеров все мозги выедят.
Когда требования бизнеса к ИТ не нужны: если и бизнес и ИТ не знают, что будет через неделю.
Ожидаемые выгоды для бизнеса и ИТ от выявления и формализации требований бизнеса к ИТ: требования к ИТ, согласованные между бизнесом и ИТ, что может позволить:
- увеличить выгоды бизнеса и ИТ;
- а также уменьшить риски ИТ, оптимизировать затраты на ИТ, повысить управляемость ИТ.
Размеры компаний, для которых уместна эта методика: выявление требований бизнеса к ИТ уместно для компаний любых размеров. Однако, применение рассмотренной здесь методики уместно скорее для компаний от 250 пользователей ИТ.
Кому лучше использовать методику «Требования бизнеса к ИТ»: ИТ-директору, с участием руководителей направлений бизнеса (развитие, производство, маркетинг, продажи, финансы и др.) и консультантов (которые организуют все работы, иначе непонятно, почему требования бизнеса к ИТ все еще не согласованы, да и «нет пророка в своем отечестве»).
Разделы ИТ-стратегии, в которых может быть использована методика « Требования бизнеса к ИТ »: методика « Требования бизнеса к ИТ » используется при разработке раздела «Требования бизнеса к ИТ». Также, конечно, требования бизнеса к ИТ влияют на все разделы по ИТ-стратегии, так как требования надо учитывать при планировании развития всех элементов ИТ.
Варианты ИТ-стратегий, в которых используется методика « Требования бизнеса к ИТ »: в полном объеме методика требования бизнеса к ИТ чаще применяется в ИТ-стратегиях от 50 страниц и более.
| Варианты ИТ-стратегий | Используется ли методика | Что конкретно | |
 | Основа ИТ-стратегии | + — | быстрая прикидка требований к ИТ |
 | «Средняя» ИТ-стратегия | √ | выявление требований к ИТ и их приоритетов |
 | «Подробная» ИТ-стратегия | √ | выявление требований к ИТ и их приоритетов |
Обозначения: «√»: входит в вариант; «+-»: частично входит
Улучшаемые области ИТ:
Элементы ИТ, включая:
- требования к ИТ;
- а также элементы управления ИТ, включая цели ИТ, ИТ-стратегию.
Отрасли, для которых уместна эта методика: методика « Требования бизнеса к ИТ » применима для компаний всех отраслей.
Ресурсы, требуемые на разработку т ребований бизнеса к ИТ: р есурсы сильно зависят от размеров компаний, для средних по размеру компаний их можно оценить в 10-20 человеко-дней работ, а то и более.
Основные этапы выявления требований бизнеса к ИТ:
- Выявление основных направлений требований к ИТ;
- Выявление перечня конкретных требований бизнеса к ИТ;
- Оценка важности требований и устраивает ли их ИТ-поддержка;
- Выявление приоритетных требований к ИТ;
- Оценка проектов по ИТ, поддерживающих требования к ИТ, особенно приоритетные.
Подходы к разработке требований бизнеса к ИТ
Методика « Требования бизнеса к ИТ » (как и еще ряд методик согласования ИТ и бизнеса), разработана Александром Михайловым на базе методик стратегического планирования ИТ и бизнеса, практическом опыте консалтинга и обучения, ряде публикаций по ИТ-стратегиям и улучшению управления ИТ:
Методики улучшения управления ИТ, согласования ИТ и бизнеса, разработки ИТ-стратегий, а также элементы ИТ, которые надо учитывать при планировании развития ИТ на 1-3 года рассмотрены в книге Александра Михайлова «ИТ стратегия: лучшие международные и российские практики», 450 страниц:
Вот место методики « Требования бизнеса к ИТ » среди других методик, предложенных А.Михайловым:
Статьи по этой теме:
- Михайлов А. «Требования бизнеса к ИТ: что и как надо планировать на 1 год и более, как это учесть в ИТ-стратегии и стратегии цифровой трансформации бизнеса. Как выжать из ИТ всё и еще немного?«, 2019
- Михайлов А. книга «ИТ-стратегия для гендиректора: выжми из ИТ все! Как руководителю компании увеличить выгоды от ИТ, снизить риски ИТ, оптимизировать и улучшить контроль ИТ» , 140 страниц
- Михайлов А. «ИТ и бизнес: как планировать улучшения для своей компании?«, дискуссия на портале Globalcio, февраль, 2018
- Михайлов А. «Оценка потенциала оптимизации ИТ: какие элементы ИТ улучшить в первую очередь? Главы из новой книги по ИТ-стратегии», дискуссия на портале Globalcio , январь, 2016
- Михайлов А. ИТ стратегия: видение, миссия, стратегические цели ИТ. Неужели это Вам надо? Директор Информационной Службы, N3, 2012
- Михайлов А. “Бизнес хочет, чтобы ИТ одновременно развивались в трех разных направлениях: повышение выгод для бизнеса, сокращение затрат, повышение прозрачности работы” интервью представителям журнала «Открытые системы» с 9-ого Российского IT Management Forum, 24 мая 2012
- Михайлов А. Стратегическое управление ИТ: видение, миссия, стратегические цели ИТ. CIO, N1-2, 2011
Типовые варианты использования
методики « Требования бизнеса к ИТ »
Методика « Требования бизнеса к ИТ » используется для улучшения управления ИТ в ряде предлагаемых на этом сайте типовых услуг:
| Услуги | Включает в себя методик у | Что конкретно | ||
| а) | | Обучение по ИТ-стратегии, с параллельной разработкой основы ИТ-стратегии на 15-20 слайдов, для малых компаний | ||
| б) | | Совместная с консультантами разработка ИТ-стратегии на 50-150 страниц, для средних компаний | √ | требования к ИТ, их приоритеты |
| в) | | Консалтинг по разработке ИТ-стратегии на 150-300 страниц, для крупных компаний | √ | требования к ИТ, их приоритеты |
| г) |  | Оптимизация ИТ (выбор улучшаемых элементов ИТ и методик) | √ | требования к ИТ, их приоритеты |
| д) |  | Совместная с гендиректором оптимизация ИТ под требования бизнеса, увеличение выгод от ИТ для бизнеса | √ | требования к ИТ, их приоритеты |
| е) |  | Планирование цифровой трансформации бизнеса | √ | требования к ИТ, их приоритеты |
Обозначения: «√»: входит в вариант; «+-»: частично входит
б) в рамках разработки «средней» ИТ-стратегии на 50 и более страниц (2-3 календарных месяца, от 50 человеко-дней) в рамках услуги «Совместная с консультантами разработка ИТ-стратегии на 50-150 страниц, для средних компаний»:
в) в рамках разработки «подробной» ИТ-стратегии в рамках услуги «Консалтинг по разработке ИТ-стратегии на 150-300 страниц, для крупных компаний».
г) как отдельный консалтинговый проект (2-3 календарных месяца, 30-60 человеко-дней работ, в рамках услуги «Оптимизация ИТ«, уместно для крупных и средних компаний):
д) частично улучшение управления ИТ выполняется в рамках услуги «Совместная с гендиректором оптимизация ИТ под требования бизнеса», в рамках согласования требований бизнеса к ИТ, целей ИТ и их связей с проектами по ИТ.
Источник: www.info-strategy.ru
Как малому и среднему бизнесу превратить обычную ИТ-инфраструктуру в надежную?
Как только речь заходит о надежности ИТ-инфраструктуры, в разговоре неизбежно всплывают те самые «девятки» — обычно их три или четыре (99.9%, 99.99%). Чаще всего они ассоциируются с высокой надежностью, доступностью ИТ-сервисов в ЦОДе или облаке. При этом у ЦОДа, как правило, все дублируется — отсюда и надежность.
Серверы, СХД, сетевые устройства, лучи электропитания, непременные дизель-генераторы и т.д. Если что-то выходит из строя, «резервная» ИТ-инфраструктура это сразу подхватывает. Это хороший, но дорогой подход! Как только его начинает примерять на себя, допустим, малый или средний бизнес, его владельцы понимают — надо потратить миллионы, чтобы сделать все правильно. А их нет.
Бизнес не готов закапывать деньги в защиту от того, что может никогда и не произойти. Полный перенос инфраструктуры в облако — тоже не панацея. Возникает целый ряд вопросов — от защиты инвестиций до чисто технических вроде эффекта «плохого соседа» в облаке и падения производительности. Между тем малым и средним компаниям надежность сегодня нужна гораздо больше, чем раньше.
Повышенная надежность ИТ — почему сейчас?
В связи с обостряющейся конкуренцией на фоне перманентного кризиса СМБ-компании вынуждены проводить гораздо больший объем изменений в бизнесе, чем два-три года назад. А ИТ должны успевать за этими инициативами. Это система с обратной связью: если ИТ начинают успешно поддерживать меняющийся бизнес, последний начинает хотеть большего. То есть период стабильности инфраструктуры и информационных систем сильно сокращается. А требования бизнеса к количеству и качеству изменений растут: становятся нужны уже не десятки, а сотни изменений в год.
Зависимость бизнеса от ИТ возрастает. Вместе с этим значительно повышаются требования к надежности и отказоустойчивости ИТ-инфраструктуры, ведь все должно работать как часы. Но часы оказываются дороговаты. Поэтому так часто СМБ покружит-покружит около надежности — и оставляет инфраструктуру «как есть».
Облако не снимает всех болей заказчика
Например, из двух интернет-каналов, по которым сотрудники небольшой региональной компании подключаются к облачной CRM-системе, один может не работать несколько дней, а резервный быть слишком медленным. Говорить о нормальной работе бизнеса здесь не приходится. Крупным же компаниям корпоративные политики могут просто запретить вынос данных в облако.
В поисках надежности: альтернативный путь
Но выход из тупика есть. Это сервисная обвязка обычной ИТ-инфраструктуры. Путь, при котором инфраструктура дополняется ИТ-услугами, позволяющими снизить число сбоев или уменьшить их последствия, сделав ее и бизнес надежнее.
Сервисная обвязка обычной ИТ-инфраструктуры: что в нее входит
- Комплексный ИТ-аудит
Перед тем как прицельно заниматься повышением надежности ИТ-инфраструктуры, ее обязательно нужно осмотреть. И получить полную картину состояния дел (что можно починить, что заменить, что оставить). Особенно если инфраструктура не новая, а сильно пожившая. При этом, возможно, СМБ-компании придется не добавлять серверы, а, напротив, избавляться от каких-то из них.
Потому что они успели сильно устареть и, скорее, снижают надежность инфраструктуры, чем повышают ее. Кроме «карты местности» (что и где), правильный ИТ-аудит дает и «дорожную карту» (что, когда и как делать, чтобы начать нормальное ИТ-обслуживание). Эти две «карты» — главная ценность аудита для заказчика.
- Управление инцидентами и проактивный мониторинг
Это выстроенные, настоящие ИТ-процессы, отвечающие масштабам и уровню ИТ-зрелости организации и ее территориальных единиц. И позволяющие предотвратить до 80% ИТ-инцидентов прежде, чем они начнут влиять на работу пользователей и организации в целом. А также в три-пять раз быстрее, чем это происходило раньше, решить оставшиеся 20%.
Такой результат возможен, только если к процессам прилагаются современные инструменты. Например, сервис централизованного мониторинга и контроля (СЦМК), настроенный под каждый сервер компании-заказчика. Сервис автоматически выявляет первые признаки ИТ-инцидента и мгновенно сигнализирует команде экспертов, передавая все необходимые для диагностики и решения данные. ИТ-эксперты, опираясь на объективные данные из сервиса, оперативно решают каждый инцидент самым оптимальным способом, действуя по четко определенным правилам процесса управления инцидентами.
В процессы упакованы и компетенции (по сети, серверам, операционным системам Windows, Linux и пр.). Таким образом, правильно выстроенные в ИТ-компании или у заказчика процессы становятся удобным проводником компетенций, которые оказываются доступными в нужном месте в нужное время.
Компетенции дороги. Чтобы оптимизировать их, сервисные компании пользуются знакомой моделью из нескольких линий техподдержки, фильтрующих поток запросов и закрывающих их на линии с минимальными достаточными компетенции.
Например, специалист 1-й линии сначала регистрирует инцидент, затем, понимая, что он слишком сложен и его решение займет заведомо больше 15 минут, передает его («эскалирует») на 2-ю линию. А у себя дисциплинированно закрывает. Инженер со 2-й линии получает задокументированные результаты расследования инцидента и решает новый для своей линии инцидент за один час, согласно SLA. Затягивания времени решения до нескольких дней не происходит, потому что каждый специалист хорошо понимает процесс, его риски (выпадение из SLA — потеря лояльности клиента, штраф для своей компании) и выгоды работы по нему (нет перерасхода ресурсов компании, ИТ-обслуживание идет качественно, соблюдаются KPI).
- Управление проблемами и централизованное управление изменениями
Качественное ИТ-обслуживание — это не только отлаженная работа с ИТ-инцидентами, но и управление проблемами. То есть выявление и устранение корневых причин, которые раз за разом порождают инциденты.
Тут снова неоценимую помощь дают данные, поступающие из СЦМК к командам компетентных специалистов, способных их верно интерпретировать. Однако, вопреки сложившемуся мнению, все это стоит совсем не баснословных, а вполне разумных денег. Потому что, работая с компанией-клиентом из 50 сотрудников, компетентный ИТ-специалист тратит всего три-четыре часа в месяц на выявление и ликвидацию даже самых сложных проблем. При условии, что он действительно компетентен, пользуется автоматизированными инструментами мониторинга и анализа, базой знаний, которые избавляют его от большей части рутинных действий. И если он действительно привык работать внутри процесса «Управление проблемами».
Но и этот набор ИТ-сервисов еще не обеспечивает СМБ-компании полностью спокойной жизни. Частый случай: придя на работу, сотрудники отдела продаж или, скажем, бухгалтерии, обнаруживают, что одно из бизнес-приложений не подключается. Проходит половина рабочего дня, и выясняется, что обновление на сервер, где работает приложение, штатный ИТ-специалист поставил, а про обновление для рабочих станций забыл. Причина простоя целого отдела — незапланированные и несогласованные изменения в ИТ.
Чтобы ничего такого не случалось, необходим процесс управления изменениями, который подразумевает, что для каждого изменения заранее готовится план, согласованный со всеми заинтересованными сторонами и техническим директором. Нужен и план «отката» в исходное состояние, если что-то пойдет не так. План проверки результатов.
А еще — полное и точное документирование проведенных изменений. Кстати, получение и этого ИТ-процесса — тоже не слишком дорого для СМБ. Потому что на 50 сотрудников у исполнителя уходит лишь пять часов работы в квартал (один клиент среднего масштаба). При условии, что есть инструменты, которые отслеживают ход и, главное, результаты изменений по сценарию «было — стало». А сами изменения проходят по понятному регламенту и проводятся сотрудниками, компетентными именно на этом участке (специалистами по серверам, а не людьми из службы HelpDesk).
- Гибридная инфраструктура
Представьте, что ваш автомобиль не завелся. Но через пять минут после этого к вам приехало такси. Без звонка. Вас отвезли на работу, а вечером привезли домой. На следующее утро вы снова начали ездить на своей качественно починенной машине.
В ИТ ровно по тому же принципу работает гибридная инфраструктура. Не нужно полностью переходить в облака или дублировать каждый сервер — это не панацея. Но можно продублировать в облаке критичные сервисы (электронную почту, бизнес-приложения ERP, СЭД, CRM и т.п.). При этом «уменьшенная копия» российской бухгалтерской программы в облаке для небольшой компании может стоить всего 5 000 руб. в месяц. Это доли процента от стоимости второго сервера, который защищал бы компанию от того, что может не случиться.
Гибридная инфраструктура работает иначе: если физический сервер все же «умер» и нужно время на его восстановление, то благодаря гибридной инфраструктуре у компании будет «запасной план», который сработает автоматически и очень быстро— через несколько минут, максимум — часов. В зависимости от приобретенного варианта услуги вся компания продолжит работу в «облачной» копии приложения.
- Сайзинг ресурсов в традиционной инфраструктуре
У средних компаний есть и еще одна беда. Если компания растет даже со средней скоростью, не ставя рекордов, то через три-пять лет она упрется в производительность серверов. ПО начинает «тормозить», и будет очень трудно выяснить, какое именно, почему и что делать, а следовательно, и понять, какие ресурсы и на сколько увеличить.
Покупка нового сервера «вслепую», как правило, ничего не меняет, тем более, что к нему просят докупить «память», которая позже оказывается не нужна… Потом что-то еще — с тем же результатом.
Современная сервисная компания может решить эту проблему довольно легко с помощью автоматизированной оценки достаточности и сайзинга ресурсов. И тогда нехватка, скажем, дискового места в системе не станет дорогостоящим сюрпризом для бизнеса, так как о ней будет известно за полгода, и можно будет спокойно спланировать и сделать целевую покупку, не переплатив.
Итого
Если «обвязать» ИТ-инфраструктуру хотя бы базовой частью рассмотренных сервисов (от «входного» ИТ-аудита до грамотного и недорогого управления проблемами и изменениями), то практически любая СМБ-компания может забыть, что ее ИТ-инфраструктура когда-то была не отказоустойчива или недостаточно надежна. Уровень надежности будет оптимальным (99,9%) или даже очень высоким (99,99%, 99,999%) благодаря более сложной части «сервисной обвязки», которая оправдана, только если этого действительно требует характер бизнеса или особая ситуация на рынке.
Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALP Group
Источник: kontur.ru
