1. Статьи
Заметки пользователей
16.06.2010 12:05
PDF
40432
110

Из одной крайности в другую

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

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

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

110 комментариев
Оставлять комментарии могут только авторизованные пользователи
Robot_NagNews
Robot_NagNews

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

 

Полный текст новости

Гость SHU
Гость SHU

Интересная, правдивая статья.

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

>

Гость ichthyandr
Гость ichthyandr

.... и чо? ))))))

edwin
edwin

Автор молодец - вопрос постарался осветить доступно и в тоже время развернуто.

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

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

Со всеми вытекающими для персонала.

Skylord
Skylord

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

На Западе все это потихоньку начинают осознавать и думать, что с этим делать. Окончательного рецепта, понятное дело, нет, но хотя бы есть понимание, что "интеллектуальный капитал компании" - это, как ни крути, нематериальные активы, которые увеличивают гудвил, который вполне нормально можно отразить в отчетности по МСФО и увеличить капитализацию. А у нас в стране и гудвила-то как такового нет по РСБУ - так и на фига мозг себе ломать? Заказать у консалтеров инструкций для персонала, нанять гастарбайтеров работать - и ништяк. А на деньги лучше оборудования подороже купить - активы как никак и в отчетности отображаются красиво, не то что хрень всякая. :-)

dmitr2t
dmitr2t

Все на 100% правда. У нас сначала была маленькая компания и руководство прекрасно понимало что кадры решают все. После нас купил один известный провайдер, зарплаты всем порезали, народ разбежался. Говоря "незаменимых людей не бывает" понабрали людей, ну ладно админов нашли, а вот те кто сеть держат в рабочем состоянии брали "оптом" т.к. на такую зп (которую выставило головное управление) шли только школьники :) В результате сейчас абоненты от них бегут - бегом бегут!

rs
rs

Надо понимать что и задачи решаются совсем разного масштаба. Вариантов два.

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

2. Забить на завоевание мира, найти свою маленькую нишу в маленькой компании(а то вовсе ИП) и делать там свой маленький гешефт

mantyr
mantyr

Увы, но этот косяк мироздания не лечится.

Roman Epifanov
Roman Epifanov

Да я вот тоже "Сеть" строил, а потом шеф продал, в месте со мной вместе в "комплекте". Новый оператор выкинул! все оборудование, и поставил свое, так проще. В крупной конторе всем наплевать, даже понятия не имеют как это работает. А инженеры - тоже винтики в большой машине.

Такой процесс во всех отраслях. Появляется технология, на мелких обкатывается потом массовая "Индустриализация" Себестоимость стремится к 0 потом стагнация. Ну и остаются пирамиды и тропосферные линии связи. А самое главное и люди не нужны-то. :-(

Rivia
Rivia
Да я вот тоже "Сеть" строил, а потом шеф продал, в месте со мной вместе в "комплекте". Новый оператор выкинул! все оборудование, и поставил свое, так проще. В крупной конторе всем наплевать, даже понятия не имеют как это работает. А инженеры - тоже винтики в большой машине.

Такой процесс во всех отраслях. Появляется технология, на мелких обкатывается потом массовая "Индустриализация" Себестоимость стремится к 0 потом стагнация. Ну и остаются пирамиды и тропосферные линии связи. А самое главное и люди не нужны-то. :-(

Да как-то везде так -) Уже стркутуры ради структур, а не людей. А вообще тема скорее для философии, нежели чем телеком.