ИТ аутсорсинг, it-premium

it_premium


Блог компании IT-Premium


Что такое SLA
mprokopov
Один из моих первых скетчей
sla

Построение основных процессов. Финал.
mprokopov
Подытожим субботнее и финальное вторничное обсуждение.

Карта процессов готова, вот она.

Map-final

В процессе финализации были добавлены потребности в "Широком спектре услуг", это когда мы включаем в свой каталог услуги, которые предоставляются другими компаниями и являемся, фактически, одним окном для подачи заявки клиенту, будь-то вопрос по 1С, телефонии или печати.

Также в потребности был добавлен кубик "Взаимодействие с сервис-деск клиента", так как у крупных клиентов уже есть собственный сервис-деск и нам необходимо регистрировать запросы и взаимодействовать именно с этой системой, и это непреложное требование заказчика.

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

Сами связи основных процессов поменяли название, но сути своей не изменили.

Все, первый этап по созданию карты процессов завершен.

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

Итак, наше резюме работы с Романом:
Для нашей компании не так то просто было определить как сегментацию клиентов так и продукты и, что самое интересное, потребности клиентов.
В процессе работы с Романом неясные места становились все более ясными, и, в результате "домашней работы" у меня получилось построить карту процессов самостоятельно от начала и до конца!
Считаю это большой заслугой Романа, как человека, который четко и ясно может донести мысль и вложить ее в мозг заказчику.
Спасибо за проведенный эксперимент.

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

Читайте в блоге Романа пост об этом сотрудничестве.

Построение основных процессов, обсуждение второе
mprokopov
Ко второму обсуждению Роман подошел основательно :)

Потребности клиентов были переформулированы в следующий список:

  • При запросе на обслуживание исполнитель сразу приступает к работе

  • Взаимодействие происходит с отдельно выделенным специалистом

  • При обращении заявка клиента сразу попадает в работу

  • Время устранения неисправности по заявке минимально

  • Подать заявку очень просто

  • Для решения выявленной проблемы достаточно подать заявку

  • Специалисты исполнителя сами выявляют возможные и текущие проблемы

  • За помощью можно обратиться в любой момент времени

  • Соблюдение условий SLA

  • Найти оптимальный размер затрат на обслуживание

Сами клиенты скомпонованы в такие группы:

  • Компании с готовыми требованиями к SLA (как правило представительства зарубежных компаний)

  • Компании, переходящие на аутсорс ИТ (например, от собственного штата специалистов)

  • Небольшие компании, которым необходимо обслуживание по требованию (нет специалистов совсем)

Которым предложены такие продукты:

  • Аудит ИТ системы

  • Абонентское обслуживание

  • Инсталляция и настройка

  • Устранение возникшей проблемы

"Аудит ИТ систем" это необходимый продукт, который идет перед и вместе с абонентским обслуживанием.

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

Для каждой потребности были определены кубики основных процессов.

  • При запросе на обслуживание исполнитель сразу приступает к работе -> выполнение заявки

  • Взаимодействие происходит с отдельно выделенным специалистом -> прием заявок

  • При обращении заявка клиента сразу попадает в работу -> выполнение заявки

  • Время устранения неисправности по заявке минимально -> выполнение заявки

  • Подать заявку очень просто -> прием заявок

  • Для решения выявленной проблемы достаточно подать заявку -> прием заявок

  • Специалисты исполнителя сами выявляют возможные и текущие проблемы -> мониторинг систем ИТ заказчика

  • За помощью можно обратиться в любой момент времени -> прием заявок

  • Соблюдение условий SLA -> выполнение заявки

  • Найти оптимальный размер затрат на обслуживание -> согласование SLA

Таким образом у нас появилось всего четыре "кубика". Это "прием заявки", "выполнение заявки", "мониторинг ИТ систем заказчика" и "Согласование SLA".

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



В целом с основными процессам все, следующим этапом идет определение вспомогательных процессов.

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

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

вспомогательные процессы

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

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

процессы управления

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

Map use to be1


Посетите блог Романа Зайцева "
Управление бизнес процессами"

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

Наша основная деятельность это производство ИТ услуг или, как сейчас часто говорят, ИТ-аутсорсинг.

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

С нашей стороны были слишком обобщенные формулировки:

  • непрерывность работы ИТ-систем

  • производство ИТ услуг с согласованными параметрами

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

В итоге мы определились на следующем списке потребностей:

  • Время реакции на обращение

  • Время устранения инцидента

  • Время решения запроса на обслуживание

  • Простота подачи обращения (не должно быть сложно сгенерировать обращение)

  • Индивидуальное обслуживание

  • Решение текущих проблем (выявленых заказчиком)

  • Постоянное сопровождение (периодическое выявление проблем клиента)

Первые три пункта и есть гарантия в том, что обращение будет обработано и решено в понятный срок.

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

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

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

Наша текущая версия основных процессов на текущем этапе такая:

  1. Заключение договора об уровне обслуживания.

  2. Прием обращений пользователей.

  3. Классификация обращений и назначение ответственных.

  4. Решение и закрытие обращений.

  5. Генерация отчетности по обращениям/услугам.

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

Stay tuned!

Посетите блог Романа Зайцева "Управление бизнес процессами"

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

Мы прошли конкурсный отбор для участия в составлении карты процессов на проекте Романа Зайцева об управлении бизнес-процессами и системном мышлении. С 16 сентября начнется наше с Романом взаимодействие и совместная разработка карты основных бинес-процессов.

В качестве первого шага нам необходимо отправить Роману краткое описание бизнес-процессов.

Суть бизнеса в двух словах: оказание ИТ услуг и реализация ИТ проектов. Существует целая методология, которая описывает процессы оказания ИТ услуг под названием ITIL. В том или ином виде мы стараемся использовать концепции, затронутые в книге, в своей работе.
Суть оказания ИТ услуг (что и составляет наши основные процессы), в следующем:
1. Согласовать понятие "качества" услуги, договориться, какие работы в нее входят, какие параметры мониторим (например, время реакции на запрос и время решения) и договариваемся о стоимости. Этот этап является "продажей" услуги и на выходе генерируется "договор с уровнем обслуживания". Иногда (раз в несколько лет) инициируется пересмотр договора.
2. Прием обращений по ИТ услугам от сотрудников клиента. По телефону в нашем контакт-центре, либо на общий e-mail.
3. Классификация обращений по услугам.
4. Решение и закрытие обращений по услугам.
Шаги 2-4 повторяются для каждого обращения от клиента.
5. По окончании периода (месяц) клиент получает отчет по потреблению услуг/трудозатратам.
6. Есть процедура "увольнения" клиента, когда закрываются доступы, подготавливается документация и прекращается действия по договору с клиентом.
Также есть процессы реализации ИТ проектов для клиента, запросы на которые чаще всего возникают в процессе оказания ИТ услуг.
В общем случае алгоритм таков.
1. Сбор требований по проекту.
2. Составление техзадания (иногда даже устно)
3. Выполнение работ по графику проекта.
4. Сдача проекта в эксплуатацию.

Продолжение следует. Stay tuned.

Маркетинг может привести к переосмыслению бизнес-модели и какое отношение к этому имеют магниты?
mprokopov
Прежде чем перейти к бизнес-моделированию, дорогие мои, попрошу вас насладиться этим видео, где великий физик Ричард Фейнман легко и просто объясняет сложнейшие вещи, например, почему магниты отталкиваются, и насколько вопрос "Почему?" может завести нас далеко.


Очень рекомендую к прочтению его автобиографическую книгу "Вы, наверное, шутите мистер Фейнман".

Так вот, выруливая на прямую "привлечения" клиентов и вникая в тонкости маркетинга я стал задаваться такими вопросами "А почему это работает именно так? Кто наша целевая аудитория? Что мы предлагаем? Как мы предлагаем?".

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

Поэтому я приобрел книгу для iPad "Построение бизнес-моделей", а с ней и приложение Business Model Toolbox.



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

Так книга разделяет бизнес на три категории: инновационный, клиентский и инфраструктурный.

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

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

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

И здесь до меня внезапно доходит, что мы пробуем все три модели совместить в одном предприятии! Таким образом наш маркетинг необходимо начинать с правильного проектирования именно бизнес-модели. Именно это имел в виду Фейнман, когда говорил о том, что вопросы "Почему?" могут завести слишком далеко. О наших успехах на этом поприще я постараюсь рассказать в следующих постах.

А по какой бизнес-модели работает ваш бизнес?

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

После 18:00 сотрудниками IT-Premium Вадим был погружен в автомобиль и вывезен в район Труханова острова.

_MG_7217
Первые попытки встать на доску

_MG_7233
Через каких-то несколько попыток уже получаем наслаждение от процесса.

_MG_7302

_MG_7341
Саша тоже освоил вейк.

_MG_7375

_MG_7379
Максиму тоже удалось встать на доску.

_MG_7383
Йу-х-у-у-у.

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

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

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

Большие корпорации могут себе позволить участие в Формуле 1, создавая и управляя самыми быстрыми гоночными автомобилями. У них для этого есть средства.
Однако победу в гонках не может обеспечить один единственный гонщик. Машина должна быть идеальной, и только слаженное взаимодействие гениального гонщика и эффективной машины может принести успех. И в борьбе за совершенство техники есть свои призы - это Кубок Конструкторов, которым отмечают выдающиеся конструкторские команды.

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

формула 1

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

povozka

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

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

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

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

Для чего их вообще описывать? Позвольте поведать небольшую историю. Мы стартовали бизнес в 2007 году, развивая его постепенно, наращивая клиентскую базу, набирая сотрудников и делали это, в основном, по наитию. То есть примерно так: зашиваемся при приеме заявок, давай примем на работу еще одного системного администратора. Приняли. Заявок стало больше и чаще, давай примем еще одного. Приняли. Не хватает времени для возни с бумажками и договорами, давай принимать девочку. Нашли годную девочку и приняли на работу. Знакомо? А что происходит следующим шагом?

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

Оказывается можно, и для этого необходимо описать как работает бизнес с точки зрения процессного подхода. Рассмотрим на примере "девочки", которая стала создавать счета и отправлять клиентам. Зачем это делать? Как делать это лучше? На эти вопросы должна ответить модель процесса. У каждого процесса есть вход и выход.


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

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

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

Каким языком можно пользоваться для описания процессов?

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

Пример выше будет выглядеть так:

BP-01 - Создание счета
Актор: бухгалтер
Основной поток

  1. Подходит дата/время для создания счетов

  2. Актор создает счет в учетной системе и отправляет на e-mail контрагенту

  3. Клиент получает счет

Расширения
1a

1a1. Актор получает запрос на создание счета от менеджера клиента
1a2. Переход к п. 2

Вот более расширенный пример текстового описания бизнес-процессов.

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

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

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

Доклад на ITSM Days
mprokopov
Рассказал немного о принципах применения ITIL/ITSM в малом бизнесе на мероприятии ITSM Days в Киеве.

Видео необрезанное, внутри три интересных доклада. Enjoy.


?

Log in

No account? Create an account