Разработка ПО имеет специфические особенности и свои отличия от управления проектами в других областях человеческой деятельности. В одной из статей мы уже рассказывали о 3 факторах, которыми обязан владеть руководитель проектов что бы довести проект до успешного заверения. Одним таким элементом является владение фреймворком (методологией). Путешествуя по Хабру мы наткнулись на одну интересную статью об обзоре 7 основных моделей разработки ПО, которую и хочу предложить вашему вниманию сегодня.
Предварительные замечания:
автор в статье рассказывает о 7 моделях разработки ПО: каскадная модель, V-модель, инкрементная модель, итеративная модель и спиральная модель. Так же к моделям причисляет RAD и Agile. Но последние две, по нашему мнению, скорее относятся к методологии разработки не же ли чем к моделям . Так Angile это вообще семейство включающее в себя Scrum, FDD, XP, Lean, и др.
Вообщем судить Вам, дорогие читатели!
Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices . Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны наиболее популярные и общие методологии, с которыми вы регулярно сталкиваетесь при разработке ПО.
3. Шаблон бизнес-модели
1. «Waterfall Model» (каскадная модель или «водопад»)
Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах.
Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена.
Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.
Когда использовать каскадную методологию?
- Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
- Нет проблем с доступностью программистов нужной квалификации.
- В относительно небольших проектах.
2. «V-Model»
Секрет Стива Джобса и три бизнес модели
Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта , находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.
Пример нашей работы на основе V-методологии — мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.
Когда использовать V-модель?
- Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
- Для малых и средних проектов, где требования четко определены и фиксированы.
- В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.
3. «Incremental Model» (инкрементная модель)
В инкрементной модели полные требования к системе делятся на различные сборки. Терминология часто используется для описания поэтапной сборки ПО. Имеют место несколько циклов разработки, и вместе они составляют жизненный цикл «мульти-водопад». Цикл разделен на более мелкие легко создаваемые модули.
Каждый модуль проходит через фазы определения требований, проектирования, кодирования, внедрения и тестирования. Процедура разработки по инкрементной модели предполагает выпуск на первом большом этапе продукта в базовой функциональности, а затем уже последовательное добавление новых функций, так называемых «инкрементов». Процесс продолжается до тех пор, пока не будет создана полная система.
Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы.
Когда использовать инкрементную модель?
- Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
- Требуется ранний вывод продукта на рынок.
- Есть несколько рисковых фич или целей.
4. «RAD Model» (rapid application development model или быстрая разработка приложений)
RAD-модель — разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.
Модель быстрой разработки приложений включает следующие фазы:
- Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
- Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
- Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
- Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
- Тестирование: тестируются новые компоненты и интерфейсы.
Когда используется RAD-модель?
Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.
5. «Agile Model» (гибкая методология разработки)
В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.
В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:
- отчёт о проделанной работе с момента последнего Scrum’a;
- список задач, которые сотрудник должен выполнить до следующего собрания;
- затруднения, возникшие в ходе работы.
Методология подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка. Соответственно, в процессе реализации требования изменяются. Стоит вспомнить класс творческих людей, которым свойственно генерировать, выдавать и опробовать новые идеи еженедельно или даже ежедневно. Гибкая разработка лучше всего подходит для этого психотипа руководителей.
Когда использовать Agile?
- Когда потребности пользователей постоянно меняются в динамическом бизнесе.
- Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
- В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.
6. «Iterative Model» (итеративная или итерационная модель)
Итерационная модель жизненного цикла не требует для начала полной спецификации требований. Вместо этого, создание начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется. Версия может быть неидеальна, главное, чтобы она работала. Понимая конечную цель, мы стремимся к ней так, чтобы каждый шаг был результативен, а каждая версия — работоспособна.
На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.
Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале — в мыслях, затем — на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.
Когда оптимально использовать итеративную модель?
- Требования к конечной системе заранее четко определены и понятны.
- Проект большой или очень большой.
- Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.
7. «Spiral Model» (спиральная модель)
«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.
Спиральная модель предполагает 4 этапа для каждого витка:
- планирование;
- анализ рисков;
- конструирование;
- оценка результата и при удовлетворительном качестве переход к новому витку.
Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование. На проекте по разработке СЭД для ОДУ Сибири СО ЕЭС два совещания об изменении кодификации разделов электронного архива занимают в 10 раз больше времени, чем объединение двух папок программистом. Государственные проекты, в которых мы участвовали, начинались с подготовки экспертным сообществом дорогостоящей концепции, которая отнюдь не всегда бесполезна, поскольку окупается в масштабах страны.
Итог
На слайде продемонстрированы различия двух наиболее распространенных методологий.
В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.
Источник: ipiskunov.blogspot.com
Инфомаркетинг. Что такое и в чем отличие от инфобизнеса
Инфомаркетинг и Инфобизнес — это не синонимы. Это вообще про разное. Хотя с виду кажется одним и тем же.
Инфомаркетинг. Исходные позиции
Начнем с истоков. В «Племени» лежит табличка, иллюстрирующая волны развития маркетинга.
Коротко, о чем там. Примерно до 1970-х годов рулил продукт (то есть «Физика» в нашей терминологии). С 1970-х пошел подъем «Алхимии». Это когда усилия маркетологов переключились с методов продаж на способы лучшего ублажения аудитории. Кастомные решения стали забарывать массовый выпуск однотипного.
И в тех же 70-х годах преимущество стали получать те, кто начал создавать офферы на базе информации. То есть фронт-эндом и/или бонусами стал не товар или услуга, а информация. Видеозапись, аудиозапись, книга, мини-книга, семинар, демонстрация, лекция, консультация и т.д. Информация, заточенная под какой-то сегмент аудитории (это очень важно). Хотя основной продаваемый продукт оставался тем же самым.
То есть инфомаркетинг — это не продажа информации ради самой продажи. Это продажа или дарение информации, как часть общего маркетинга. Как инструмент протаскивания клиента по всей воронке принятия решения о покупке.
Дэн Кеннеди использует этот трюк в качестве начального элемента своих умных продаж. Это же лежит в основе его базового курса «Magnetic marketing system». И это именно тот самый контент-маркетинг, инбаунд, лидогенерация которые сегодня переизобретают в интернете.
Таким образом инфомаркетинг — это средство усиления существующего бизнеса с любыми корнями («Физика», «Метафизика» или «Алхимия»).
В чем отличие инфомаркетинга от инфобизнеса
В инфобизнесе же ситуация обратная. Тут информация выступает в роли конечного товара. Как самодостаточный продукт. Тут информацию продают ради продажи. Тут цель — сразу получить денег. Да, в инфобизнесе информация может тоже выступать в роли фронт-энда.
Но цель всегда — получить деньги. Потому что маржинальность инфобизнеса — от 300% и выше.
Инфобизнес — это не средство усилить существующий бизнес, это способ создать еще один бизнес на базе существующего. Это как такая побочная «ветка прокачивания». У того же Кеннеди в инфобиз приходят люди, которые работают, скажем, лет 20 подряд в продажах недвижимости, а потом упаковывают свои знания и гигантский опыт и продают это упакованное новичкам в той же нише. То есть они не подменяют и не бросают свой базовый бизнес, они создают еще один. Умный ход.
Поэтому инфобизнес вроде бы и похож на идеальный бизнес. Но это не для всех. Потому что для начала он должен базироваться на твоих интересах и увлечениях. На твоём реальном опыте. Затем, если ты ненавидишь маркетинг и рекламу — это для тебя плохой выбор. Инфобизнес — это «реши проблему и только потом продай решение».
Сначала реши проблему в своей собственной жизни. Только так твое знание будет иметь ценность.
Три модели инфобизнеса
Есть три модели инфобизнеса:
- Модель Фрэнка Керна и Эда Дейла «Underachiever». Это когда мы выискиваем недооцененные ниши, становимся там успешными и продаем свой успешный опыт другим в этой же нише.
- Модель Джо Полиша «Overachiever». Это когда мы максимально прокачиваемся в своей существующей нише и затем продаем успешный опыт другим в этой же нише.
- Модель Джеффа Пола и Дэна Кеннеди «JPDK». Тут всё немножко сложнее, но в целом похоже на предыдущую модель.
Подвох современного инфобизнеса и инфомаркетинга
Три модели ИТ-аутсорсинга: что нам делать с парадигмой
ALP ITSM обеспечивает IT-поддержку компаниям разного масштаба — от небольших офисов с 20 сотрудниками до международных фастфуд-гигантов. Мы помогаем нашим клиентам находить выгодные IT-решения, подбираем и устанавливаем оптимальные сервисы. Но недавно мы сами оказались в ситуации, когда нужно было отказываться от привычных решений и искать новые варианты. Рассказываем, как наша компания численностью 120 сотрудников переходила на отечественный почтовый продукт и что из этого вышло.
В чем разница между импортозамещением и локализацией ИТ? Для каких компаний подходят эти две стратегии? Значит ли их реализация, что от иностранного софта и оборудования нужно будет отказаться полностью? Разобраться в теме помог Сергей Идиятов, руководитель направления консалтинга ALP ITSM.
Статьи 22 августа 2022 Топ-5 рекомендаций для CEO: как локализовать IT-инфраструктуру?
Для компаний с центральным офисом в зарубежных странах санкционный кризис стал серьезным испытанием. При сохранении бизнеса в России нужно выделить IT-инфраструктуру локального офиса и сделать ее независимой и автономной от глобальной компании, объявившей об уходе из РФ. Этот «развод по-итальянски» требует четкого плана, ресурсов и крепких нервов. Как минимизировать риски, рассказывает Сергей Идиятов, руководитель направления консалтинга ALP ITSM, сервисной IT-компании холдинга ALP Group.
Возьмем торговую компанию со штатом в 100 человек, которую благополучно обслуживает ИТ-аутсорсер. Но благополучие это сохраняется лишь до тех пор, пока компания не начнет расти, и у нее не появятся новые ИТ-сервисы, от которых будет зависеть ее основная деятельность. Например, CRM-система, которая сразу поднимает количество запросов и инцидентов, скажем, на 10%.
Чтобы обработать их, организации придется докупить у своего поставщика ИТ-услуг полное время еще одного сотрудника, ведь другие занятые на проекте специалисты до отказа загружены работой (в этом аутсорсер кровно заинтересован). В лучшем случае заказчику предложат «половину человека», но она обойдется ему удельно дороже на 20-30%, т.к. аутсорсеру нужно будет покрыть свои затраты (на дорогу специалиста к клиенту и др.). При этом приобретенный втридорога сотрудник, благополучно закрыв все заявки по CRM, скорее всего, остальное время будет простаивать. А купить не 50–100%, а нужные ему 10% времени специалиста заказчик, по условиям договора, не может.
Ресурсная модель преимущественно используется компаниями с невысокой зрелостью ИТ или претерпевающими ряд непрерывных изменений
И это не особенность конкретного договора — так работает ресурсная модель ИТ-аутсорсинга, самая распространенная в среднем бизнесе. Если бы заказчик выбрал иную — сервисную — модель, то вопрос с масштабированием решился бы безболезненно. Ведь эта модель работает по схеме: «бизнес формулирует потребность (например, обработка заявок по CRM с заданным уровнем качества), а исполнитель оценивает свои затраты и дает цену». Каким образом исполнитель собирается «освоить» новый объем задач — нагрузив имеющегося специалиста или подключив дополнительные ресурсы — заказчику совершенно неважно. Главное, чтобы рост цены контракта был бы примерно пропорционален росту запросов.
Все ниже и ниже: ресурсная модель вместо сервисно-ориентированной
В другой типичной ситуации, когда бизнес экономит и не докупает нужные ресурсы, несмотря на рост объема работ по ИТ, перегруженные заявками сотрудники не стремятся отслеживать качество своих услуг и повышать интенсивность работы. Скорее, она у них со временем падает. Исполнитель при этом может спокойно «умыть руки», ведь задач стало больше, а заказчик не хочет за них доплачивать.
Уровень ИТ-сервиса здесь неизбежно страдает. Да и сама перспектива сотрудничества оказывается под угрозой, ведь стороны больше не удовлетворены друг другом. И снова в неверно выбранной ресурсной модели единственным возможным решением для клиента становится доплата за дополнительные руки, головы и время. Хотя даже это не подтолкнет аутсорсера к проактивности в решении инцидентов и проблем. Ведь в ресурсной модели поставщику услуг выгоднее продавать больше человеко-часов, а не заставлять сотрудников работать продуктивнее.
Более выгодной в этой ситуации для заказчика оказываются сервисная или сервисно-ориентированная модели ИТ-аутсорсинга. В них клиенту не нужно покупать сервис «большими кусками» — по 50% или 100% времени от специалиста на полный день. Заказчик просто добирает необходимый объем услуг в 10-20%, и получает их. Причем, с заданным уровнем качества. Затраты возрастают пропорционально.
Причем заказчик может скомпенсировать этот рост за счет контролируемого снижения SLA или перехода к схеме SmartSLA, если провайдер ИТ-аутсорсинга располагает соответствующей технологией.
Качество ИТ-обслуживания: как получить нужное
Ресурсная модель ИТ-обслуживания могла бы изжить себя в 2016 году вместе с запуском закона о запрете на заемный труд (аутстаффинг), трансформировавшись в сервисную или сервисно-ориентированную. Но во многих случаях это произошло только «на бумаге» — договоры на аутстаффинг были заменены на сервисные, без изменений в самих услугах. Потому что переход к иным моделям обслуживания требует от исполнителя глубокого и системного знания сервисного подхода ITSM, наличия полной матрицы ИТ-процессов. А главное — реального опыта использования этих процессов для заказчиков различного масштаба и уровня зрелости в ИТ.
Кроме того, чтобы эффективно использовать выбранную модель ИТ-сервиса, нужно хорошо понимать ключевые характеристики, особенности и ограничения каждой из них.
Три модели обслуживания: главные характеристики и отличия
| Удельная стоимость услуг | Высокая | Низкая | Низкая или средняя (в случае «скрытых ИТ» возникают дополнительные затраты) |
| Гибкость ценообразования | Низкая | Высокая | Высокая |
| Соблюдение SLA | Практически неприменимо | Да | Да |
| Гибкость оказания услуг | Высокая | Низкая | Высокая |
| Уровень экспертизы ИТ-команды | Зависит от компетенций конкретных специалистов | Низкий | Средний или высокий |
Сервисная модель: супер-стандартизация как главный принцип
Сервисная модель ИТ-поддержки подразумевает, что заказчик получает от исполнителя не конкретных специалистов, а обезличенные услуги с оговоренными параметрами. Например, техническую поддержку пользователей и рабочих мест, техническую поддержку бизнес-приложений, обеспечение непрерывной работы серверного ландшафта.
Каждая такая услуга решает одну или несколько ИТ-задач, что при современном уровне зависимости бизнеса от ИТ почти автоматически превращает эти задачи в «бизнесовые». Поэтому у услуг, предоставляемых в рамках сервисной модели, всегда есть согласованные с бизнесом параметры: качество, сроки, стоимость. Как быстро будет взята в работу заявка? Когда она будет решена?
Как скоро будет устранен сбой в инфраструктуре и заработает почта? На все эти вопросы есть понятные ответы, не расходящиеся с действительностью более, чем предусмотрено договором на оказание услуг.
Также у услуг в этой модели есть понятный принцип ценообразования. Например, 800 руб. в месяц за поддержку одного рабочего места. 50 руб. за одно решенное обращение. Штраф исполнителю 1000 руб. за каждый час просрочки.
В совокупности сервисная модель позволяет заказчику получить услуги нужного качества, с гарантией, по справедливой цене. Поэтому складывается ощущение, что если бизнес выберет сервисную модель ИТ-поддержки, то у него все сложится идеально. Однако, это не так. Покажем на примере.
Допустим, крупный заказчик — западная фармацевтическая или FMCG-компания, представленная в России, — покупает услуги первой линии техподдержки (прием и диагностику обращений и ИТ-инцидентов по почте, их решение в рамках SLA, установленных глобальным офисом), а также эскалацию более сложных проблем на вторую линию. В услугу входит и база знаний, к которой обращаются ИТ-специалисты. Там очень мало или почти нет опыта глубокого экспертного уровня. Но его достаточно, чтобы решать 50–70% запросов и придерживаться согласованных с заказчиком параметров качества, оставаясь в жестких рамках бюджета, а также максимальной стандартизации обслуживания — с помощью понятных регламентов и инструкций. В этой схеме уровень качества стабилен и не «завязан» на конкретного исполнителя — если они меняются, ИТ-сервис от этого не страдает.
Но есть одна досадная тонкость: принцип «действуем только в рамках SLA» распространяется даже на инциденты с самым высоким приоритетом, затрагивающие весь бизнес или его ключевые фигуры. Казалось бы, в чем проблема — достаточно задать жесткие требования к уровню сервиса, например, 15 минут на реакцию и 30 минут на решение задачи. Но, разумеется, подобный сервис оказывается крайне дорогим, особенно в масштабах международной корпорации. Поэтому корпоративный SLA, как правило, является значительно более мягким.
Совсем не редкость, когда на решение заявки с высоким приоритетом, если она не относится к общекорпоративным сервисам (ERP или электронная почта), отводятся часы или даже дни, и это будет «ОК» с точки зрения SLA. Есть даже примеры, когда стандарты сервиса процветающей международной компании вовсе не регламентируют время решения запроса.
На практике для сотрудников это часто означает «стабильно плохой сервис». Любой сотрудник компании, включая генерального директора, может ждать реакции на инцидент 2–4 часа. Еще день-два уйдет на то, чтобы ее решить. Все это время сотрудник, по сути, не может полноценно работать, и эта ситуация является совершенно нормальной с точки зрения корпоративного уровня сервиса. Получая такое «извращение» модели обслуживания, ИТ-директор вынужден решать такие инциденты аврально, обходя регламенты и снимая специалиста с другого участка, да еще и вразрез с корпоративным SLA.
Сервисно-ориентированная модель: рождение нового на стыке парадигм
Все вышеописанные ситуации указывают на очевидную вещь: в дополнение к двум господствующим моделям ИТ-обслуживания — ресурсной и сервисной — российскому бизнесу стала требоваться третья — сервисно-ориентированная. Потому что именно она объединяет сильные стороны традиционных парадигм обслуживания: исполнитель предлагает услуги с заданными параметрами качества, формируя команду специалистов «под заказчика». В этом случае клиент получает все основные преимущества сервисной модели: стабильность качества, SLA, понятное ценообразование. Добавляя к ним оперативность реагирования, гибкость управления, накопление и сохранение компетенций, присущие выделенным ИТ-командам в сервисно-ориентированной парадигме.
Новая парадигма в действии: как это работает и что получает заказчик
В новой модели большую часть времени команда работает в «сервисном режиме», обеспечивая решение задач в рамках корпоративного SLA. Но в случае форс-мажора, когда строгое следование формальному SLA становится неприемлемым, часть команды переходит в «экспертный» режим. Теперь задача решается не в общем потоке, а приоритетно и экспертно, с максимально быстрым восстановлением сервиса и последующим поиском системного решения. Причем эта процедура — штатная, насколько вообще может быть штатной работа по срочным инцидентам.
В этом случае генеральный директор уже через 20 минут получит новый аккумулятор для ноутбука, а не будет ждать стандартные 8 часов, отведенные SLA. А команда, вернувшись в «сервисный режим», начинает планомерно общаться с сервисным центром, системно решая задачу.
Сервисно-ориентированная модель позволяет закрыть потребность заказчика в качественном сервисе, не переплачивая за избыточные ресурсы. Сохраняя предсказуемость сервисной модели, она снижает уровень стандартизации ИТ в компании до приемлемого. И одновременно повышает уровень экспертизы до необходимого во внештатных или сложных ситуациях.
Однако здесь есть ловушка, которой аутсорсеру надо избегать во что бы то ни стало: преимущества работы в контексте заказчика (т.е. при «полной индивидуализации») создают соблазн возврата к ресурсной модели. А вместе с этим — ко всем ее недостаткам (переплата за невостребованные ресурсы, падение качества обслуживания, отсутствие проактивности). Чтобы избежать этого, исполнителю нужно отказаться от формирования жесткой структуры команды, когда все участники являются ключевыми. И создавать «ядро» из компетентных специалистов, создающих и сохраняющих экспертизу, плюс гибко масштабируемое окружение из сотрудников ServiceDesk, обеспечивающих «сервисные» функции.
Выбор модели ИТ-обслуживания: заключение контракта или скрытые ИТ
Сегодня компании приходят к сервисно-ориентированной модели ИТ-обслуживания двумя путями. Прямой путь имеет место, когда компания осознает необходимость высокой экспертизы у ИТ-специалистов из-за высокой ИТ-зрелости или же из-за постоянных сложных ситуаций. Скрытый же путь вынуждены применять, скажем, крупные международные компании, где официально принята централизованная сервисная модель ИТ-обслуживания, но нет сил принимать все следствия этого решения.
В последнем случае CIO, головой и креслом отвечающий за качество ИТ-сервиса на вверенном ему участке (1000 — 10 000 пользователей, крупная российская или западная компания), заключают контракт «на консультационные услуги» с локальным поставщиком ИТ. Или же в штате компании появляются таинственные «аналитики», «сотрудники инженерных служб», «техники», которые на деле являются ИТ-специалистами. По выражению одного из директоров международного производственного холдинга, возникают т.н. «скрытые ИТ».
Все они предоставляют заказчику главное — местный «спецназ», имеющий требуемый уровень экспертизы на конкретном участке ИТ или сразу на нескольких. Например, поддержку локальных бизнес-приложений медицинских представителей, или администрирование торговой системы. И возможность обратиться в собственный (или дружественный) центр компетенций, если проблеме присваивается повышенная сложность, а свои компетенции в этой части только нарабатываются или подтягиваются до нужной планки.
Разноуровневая экспертиза ключевых специалистов или команд быстрого реагирования открывает широкое поле для оптимального решения многих ИТ-задач. Это дает гарантию того, что срочные инциденты не превратятся в проблемы, серьезно влияющие на бизнес, а наиболее сложные проблемы (например, на стыке работы разных приложений, связанные с их производительностью) будут решены в короткие сроки или обнаружены заранее.
Итого: три способа решения ИТ-задач
На практике все три модели ИТ-обслуживания сегодня мирно сосуществуют на нашем ИТ-рынке. Но распределение популярности ресурсной, сервисной и сервисно-ориентированной моделей для разных сегментов рынка сильно различается. Так, около 50% средних сервисных и производственных компаний, особенно если уровень их ИТ-зрелости ниже среднего, склоняются к ресурсной модели, «арендуя» нужных специалистов. Почти 80% крупных международных компаний, например, фармацевтических или FMCG с представительствами в России — склоняются к явной сервисной или замаскированной сервисно-ориентированной. Аналогичным образом обстоят дела у розничных сетей: крупный ритейл тяготеет к сервисной и сервисно ориентированной моделям, а средний, развивающийся — к ресурсной.
Обобщая, можно сделать вывод, что ресурсная модель преимущественно используется компаниями с невысокой зрелостью ИТ. Другая категория предприятий, выбирающих эту модель — компании, претерпевающие ряд непрерывных изменений — например, рост торговой или филиальной сетей, когда гибкость «ручного управления» оказывается предпочтительнее сервисной стабильности.
И, напротив, компании с высокой зрелостью ИТ-служб, международные компании, заинтересованные в стандартизации процессов обслуживания и снижении издержек на ИТ-обслуживание при одновременном повышении его качества, предпочитают сервисную и сервисно-ориентированную модели.
Источник: alp-itsm.ru