itSMF Russia :: Ассоциации организаций и специалистов в сфере управления информационными технологиями «ИТ сервис-менеджмент форум» баннер
НОВОСТИ УЧАСТИЕ В АССОЦИАЦИИ ОБ АССОЦИАЦИИ БИБЛИОТЕКА СОБЫТИЯ ДЛЯ УЧАСТНИКОВ NEW ТРЕБУЮТСЯ СПЕЦИАЛИСТЫ БЛОГИ NEW НАБЛЮДАТЕЛЬНЫЙ СОВЕТ

 

поделиться

Присоединиться к ITSM сообществу


Состав itSMF Russia


баннер

 

 


книжный магазин itSMF



Подпишитесь на новости ITSM-сообщества

* обязательные поля
Архив рассылок >>>



facebook linkedin баннер twitter



Реестр аккредитованных учебных центров, работающих в Российской Федерации и имеющих право проводить обучение по утвержденному списку курсов ITIL®


Manager’s Certificate in IT Service Management Список ITIL Expert'ов и сервис-менеджеров России и стран СНГ



Список российских профессионалов сервис-менеджмента, обладателей сертификатов priSM




Работа для Вас: актуальные вакансии


Из одной крайности в другую
Сергей Кукса, nag.ru
Untitled Document

16.06.2010 Автор: Сергей Кукса

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

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

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

Хочу начать с такой аббревиатуры ITIL. Многие слышали это слово, нередко слышно мнение, что ITIL — это не более чем набор рекомендаций. Однако, этот «набор рекомендаций» довольно плотно вошел в жизнь крупных компаний, и понятие «поддержка третьего уровня» встречается не реже, чем «свитч третьего уровня». И если вы хотите работать с крупными структурами, вы должны, по меньшей мере, знать тот язык, на котором с вами говорят.

Не буду углубляться глубоко в эту тему, вкратце пройдусь по избранным аспектам ITSM — Information Technology Services Management — то есть обслуживание пользователей. Эта часть постоянно встречается в провайдинге.

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

Когда происходит разделение в «первой линии» остаются люди, не понимающие ничего в технологиях. В случае несерьезных проблем несколько раз я получал помощь или нужную информацию от первой линии. Но мне ни разу не удалось пробиться через первую линию в случае серьезной проблемы. Я считаю, что понимаю что-то в технологиях, но объяснить поддержке, что надо передать проблему квалифицированному инженеру не удавалось. Это было как в общении с провайдерами, так и поставщиками оборудования.

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

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

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

А вот управление изменениями — часть очень интересная. Помню по своему опыту, как делал изменения в сети: «А не сделать ли мне это? А как? Ну-ка, попробуем так… Фигня получилась!». В большой сети такое крайне рискованное занятие. Поэтому каждое изменение в сети готовится, прописывается план тестирования, план действий в случае неудачи, классифицируется и проверяется, только потом применяется в рабочей сети. Вроде правильно и разумно.

Однако, те, кто проверяет, должны потратить на это время. И, нередко, те, кто должен проверить какие-то изменения в сети на предмет корректности, банально ленятся и делают это формально. Добавлю, что люди, кто готовят и применяют изменения — часто не те, кто сеть обслуживает, да и планы тестирования пишутся нехотя и формально. В итоге, простой перенос порта из влана во влан занимает 3 дня, а одно, как заявлено, самое что ни на есть небольшое изменение кладет всю сеть.

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

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

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

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

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

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

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

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

Так что выбор оборудования для проекта не определяется только его ценой. Конечно, если проект большой, и доля оборудования в этом большая, то будут объявляться тендеры, которые играются по своим правилам, данной темы не касающиеся. Но небольшие проекты — да все равно, сколько стоит, важно чтоб не вело к увеличению числа людей, которые требуются для проекта. Поэтому если стоит везде Cisco — значит, будет Cisco. Ибо когда стоит 100 маршрутизаторов Cisco покупать один Juniper не будут, даже если он на 20 тысяч дешевле и 30% производительнее. Ведь этому Juniper-у придется учить 2-3 десятка человек, да еще, возможно, менять процедуры обслуживания, систему управления сетью и прочее, что, кстати, представляет собой отдельные проекты.

Хотелось бы описать возможное исключение из общего правила, "сказка или средний путь". Хорошо знакомый многим Ethernet-провайдерам. 

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

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

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

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

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

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

«Ни фига себе!» скажет новый технический директор, посмотрев зарплату простого сисадмина. Не важно, что сисадмин работает тут 6 лет и знает про сеть все и любую аварию диагностирует за 15 минут. «Да что они о себе думают!» скажет директор, посмотрев на зарплату техподдержки, и не важно, что половина из них решает и проблемы на уровне системных администраторов. И порежет все, «понабрав по объявлениям» замены вместо ушедших. И все будет работать. Да, качество поддержки упадет, но сбереженные деньги позволяют проводить агрессивную маркетинговую политику и приток новых пользователей, и греют душу менеджера… А через какое-то время сеть начнет спотыкаться, не выдержав новых безлимитных тарифов и роста клиентов. А новые сисадмины не могут ее исправить, так как не понимают еще, как же это работает. 

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

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

Читать статью и коментарии >>>



Помогите своим коллегам быть в курсе интересных новостей! Поделитесь!
Документ без названия


 

Приглашаем принять участие
в воркшопе ITSM Labs
баннер


баннер


баннер


Партнеры itSMF России



 Директор информационной службы
 

Information Management

Открытые системы



Московское отделение ISACA

ABPMP Russian Chapter

GlobalCIO

СоДИТ

SPb CIO Club — партнер itSMF России

Высшая школа бизнес-информатики Государственного университета – Высшей школы экономики (ВШБИ)

МИИТ

ГУУ

Московский государственный университет экономики, статистики и информатики (МЭСИ)

Факультет ВМК МГУ имени М.В. Ломоносова

Московский институт электроники и математики (МИЭМ)

Институт информационных бизнес систем



Блоги: