psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Упражнение для менеджера: мотороллер для аптеки
psilonsk


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

Письмо товарища привожу в авторской редакции.

"Привет Серег. Я в копию поставил своего друга Диму, чью проблему и опишу в письме :)

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

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

  1. Полностью отсутствует политика информационной безопасности, максимум что есть, это антивирус

  2. Сеть в офисе компании "исторически сложилась", представляет собой набор свитчей и хабов, не документирована и требует полной перестройки, система мониторинга отсутствует

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

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

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

Исходя из этого видится ряд критически важных задач, перечисленных в порядке очередности выполнения:

  1. Разработать и запустить ИБ в компании

  2. Разработать техническую архитектуру предприятия и перестроить сетевую инфраструктуру с запуском системы мониторинга и инцидентов

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

  4. Создать комплекс документации по разрабатываемому в компании софту

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

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

Собственно, вопрос для обдумывания и обсуждения: как бы вы, став таким руководителем, начали решать задачи (и те ли задачи нужно решать Диме из письма)?

Ну а те, кто хочет поработать в этом проекте, могут написать на ldsrus@mail.ru (мне писать не надо, мотороллер не мой). )



promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

  • 1

Навскидку,  из-за руля: я бы сначала привел в порядок сеть. Это 1.автоматически позволит использовать удаленное подключение для дистанционной тп. 2. Устранит часть проблем с инфраструктурой. Это снятие острых симптомов, наиболее раздражающих руководство.
Затем постепенное приведение к единой архитектуре информационной системы. Этого слоника съесть одним куском не дадут, поэтому потихоньку, начиная с наиболее крупных пунктов ( но сначала протестить на 1 мелком) Параллельно ставить оргмеры по ИБ.


О! Прям по моему профилю, тьфу на него. Сразу и в лоб: Дима решает не те задачи и не в той последовательности.

Первое, что ему надо, это взять бутылку/конфеты/чего еще и идти к начальникам смежных подразделений. Логистика там, провизоры и прочие (я про аптеки не очень). Задача номер 1: выяснить бизнес процессы, которые обслуживает ИТ. Задача номер 2: выяснить список "болячек", которые может закрыть ИТ (или которое должно закрывать, но не закрывает).

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

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

Затем софт документировать и дорабатывать, если надо.

Повторюсь, сети и ИБ тут не критикал вообще. Ни разу.

ЗЫ И да, если чего, пусть пишет. Помогу, если чего.


Edited at 2017-01-16 08:31 am (UTC)

ППКС

С процессов внутренних клиентов надо начинать

Блин, хотел сначала всё прочитать, и потом уже своё слово веское вставить, а тут уже всё сказали.

Ну почти всё.

А куда делся прежний начальник ИТ? У него был зам/помощник? Почему он не стал начальником?

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

товарищ хочет революций? Лучшее враг хорошего, как известно. ну и там "работает-не трогай".
В нашем случае мы всё централизовали. Это первое, что сразу видится и сразу принесёт результат. Ну и как было выше совершенно справедливо написано, надо собрать болячки пользователей. Это сразу повысит лояльность смежников и очень поможет далее работать.
Оптимизировать ИТ-процессы лучше пока не надо. Это такой ящик Пандоры. Можно отдел растерять.
Обучать людей нужно, если бюджет есть, конечно. Ну документация тоже нужна, но не критично, как практика показывает.

Первая задача, которую должен поставить перед собой владелец мотороллера -- убедить руководство, что все это нужно. Если до этого все работало тип-топ и руководство ничего не знает о проблемах, то убедить будет ой как непросто.
Если все это так, то я на 146% уверен, что пункты 2 и 5 придется надолго отложить.Я б начал с пунктов 3 и 4, и начал бы собирать материал для продвижения всего остального.


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

Как раз, мой профиль :) и одна из интереснейших задач
Опыт подсказывает следующее - пункт 1 переносится в самый конец, т.к. для того, чтобы начать заниматься информационной безопасностью, нужно четко иметь ответ на два вопроса: что защищать и от кого защищать. А для ответа на этот вопрос нужна документация на всю инфраструктуру, ПО, бизнес-процессы организации и т.п...
Без перестройки сетевой инфраструктуры невозможно решить другие обозначенные проблемы, а а перестройка сетей требует ее, хотя бы, минимальную документацию.
Конечно же, информации не совсем достаточно для принятия решения: единственная ли это задача, либо есть еще проблемы, непонятен бюджет, непонятны допустимые простои и время реакции и т.п., но если отталкиваться от этих данных, то порядок мне видится таким:
1. Необходимо задокументировать сеть, после чего приступить к разработке ее концепции, в которую входит безопасность, мониторинг и пр.
2. Пока идет выполнение п.1 есть время у разработчиков задокументировать свои проекты, изучить их, проанализировать и принять решение по их оптимизации с учетом новых возможностей сетевой инфраструктуры и централизации.
3. Процесс выполнения первых двух пунктов даст новому руководителю колоссальную информацию по следующим этапам работы и их приоритету: также станут понятны ресурсы, как административные, так и человеческие. Т.к. не вникнув в бизнес-процессы, а только простым взглядом "со стороны" такой план можно составить только либо имея космический бюджет и неограниченные полномочия, либо достаточно высок риск на долгое время вывести из строя какие-либо бизнес-процессы из-за их недокументированности и незаменяемости специалистов.

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

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

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

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

Первым делом нужно идти к акционеру или кто там принимает основные решения и задать вопрос: “Ремонт, реставрация, инновация?”
Сделать как было из новых материалов,
Заставить старое работать нормально,
Переделать всё начиняя с процессов.

Соответственно ценник растёт с каждым пунктом, а доходы вряд ли станут выше, но есть важные нюансы.

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

почему-то среди задач нет пункта о том, что все вот это вот: "..работу железа и сети, разработку и поддержку ПО, телефонию и обслуживание кассовых аппаратов, репликацию данных между центром и аптеками, поддержкой сайта с онлайн каталогом..." должно работать не хуже, чем всегда. Еще одна задача - сберечь сотрудников.

Edited at 2017-01-16 04:39 pm (UTC)

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

>>1. Разработать и запустить ИБ в компании
И так - ИБ. А зачем собсно ИБ? Чтоб было? Чтоб хорошо отчитаться? Какую задачу решит "запуск ИБ" в этой компании? Превентивно отвечу - никаких. Потому что в 2017 году ИБ на WinXP SP2 невозможно, бгг, а ОНО - будет, учитывая условия.
Далее - ну будет тот же антивирус стоять - И ЧТО? До тех пор пока на компы криптолокеры не ловят - всё будет работать, а главное - никак не повлияет на фактическую безопасность - потому что на компе аптеки ловить тупо нечего. Да и в офисе - тоже нечего, всё что можно украсть - проще украсть нанявшись и скопировав напрямую.
Так что ИБ, ни в каком виде, нафиг не нужен. Особенно учитывая п. 2. Особенно учитывая отсутствие понимания (в первую очередь у головы) зачем ИБ вообще конторе нужен.

>>2.Разработать техническую архитектуру предприятия и перестроить сетевую инфраструктуру с запуском системы мониторинга и инцидентов
Перестраивать - нафиг не надо, до тех пор пока работает. По одной простой причине - в таком бардаке что-то лечить/чинить/улучшать нечего, нужно строить с нуля, а на это - денег нет. Мониторинг - аналогично. Более того, мониторинг даже несколько вреден, пример: "аптека №999 не может работать! Но связь до неё есть и компы там включены! И ФИГЛИ ТОЛКУ?"
Инциденты - надо. Тупо для отчётности, для формирования понимания РЕАЛЬНЫХ проблем, приводящих к остановке или критическому ухудшению БП.

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

>>4. Создать комплекс документации по разрабатываемому в компании софту
Нужно, но опять таки, после разгребания завала по п/п 1-3.

>>5. Оптимизировать поддержку удаленных точек (привлечение удаленных администраторов или подрядчиков по договорам, разработка инструкций по решению простых проблем с проведением обучением сотрудников точек и т.д.)
Гм. А кто оплачивает банкет на них всех? А с чего это ли? Разве есть реальная необходимость доказанная топам? Да и что с ресурсами техническими для этого праздника жизни?

В целом - поддерживаю kiltum, если человеку _действительно_ надо - пусть сначало выяснит ЧТО он может сделать для компании, для улучшения КАЧЕСТВА работы - и в кратчайшие сроки.

Edited at 2017-01-17 01:52 am (UTC)

Что интересно, все из комментаторов не владея полной информацией о задаче стали предлагать и критиковать, никто не пожелал уточнить, с чего бы вдруг в компании неожиданно поменялось руководство ИТ :) Мопед не мой, но по ситуации кое чего знаю. Как уже написано выше, отдел достался в более менее исправном состоянии, но состояние это можно назвать состоянием медленно ухудшающейся стабильности. То есть оно работает как работает, "исторически сложилось" и любое изменение работы системы (процессов этой компании) сложит как карточный домик все "сбалансированные" процессы. "Перечисленные меры" - это взгляд сверху, что будет в первую очередь складываться и на что при превентивной подготовке к реорганизации работы ИТ в ответ на реорганизацию процессов работы компании необходимо в первую очередь обратить внимание.

Ряд замечаний комментаторам:
1. В компании, где везде тиам вью и торренты на каждом компе, один логин и пароль на всех, однозначно надо навести с ИБ порядок. Конечно говоря ИБ можно подразумевать что то крутое и страшное, что защитит от кулц хацкеров, но элементарный порядок никогда не помешает ;)
2. Сеть, состоящая из тучи неподписанных проводов по умолчанию не может быть оставлена "пока работает, не трогать". Особенно если в конторе всего один админ.
3. Новые задачи потребуют введения новых нагрузок на разрабов. Конечно можно пойти простым путем брать новых разрабов на каждую новую задачу, однако у муниципальных компаний бюджет не резиновый, а перед тем, как расширять штат, то есть усложняя задачу управления большей командой, неплохо бы оптимизировать что есть, научив элементарно людей работать командно и взаимозаменять друг друга при необходимости.
4. Ну хоть тут все согласны, что нужно :)
5. Пару человек, которые разьезжают под 500 км между аптеками мне кажется вполне достойный повод подумать про оптимизацию обслуживания удаленных точек и аналогично пункту 3 набор большего количества людей дежурной смены не означает, что эффективность решения задачи повысится.

Вот что удивительно, я архитектор ИТ (не PM и не руководящий), но в целом тут комментарии мне напомнили не будь в обиду сказано разрабов. Прямо стремление к усложнению задачи. А может быть у Димы все проще, он не рвется геройствовать, приводить мир к порядку, а просто хочет удержать, что работает и подготовиться к вызовам, которые ожидают его в недалеком будущем, чтобы и отдел не разбежался и программы с сетью работали и аптеки не простаивали в результате незначительных проблем ? :)

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

Только новую модель надо начинать не с абстрактных "ИТ-приоритетов", а с требований бизнеса :)

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

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

Т.е. приоритеты примерно такие: 1) чтобы все продолжило работать 2) чтобы при проблемах все можно было починить разумными силами и быстро 3) чтобы предотвращать проблемы заранее и дешевле, чем чинить их пост-фактум.

Что же касается заменяемости разработчиков ПО - тут все просто - или один незаменимый разработчик за еду, или сразу отдел, с менеджерами, тестерами, бизнес-аналитиками и все это стоимостью в 10-20 раз больше.

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

Ага, разумно. Последний абзац отличное уточнение, что нужно включить в документирование в первую очередь!

Но насчет мониторинга не согласен. Когда 150 аптек и 150 серверов с репликацией, лучше заранее узнать, что утром аптека не сможет заработать из за того, что сервак не работает, а не постфактум высылать дежурного чинить сервер, который к вечеру приедет.

Это нужно круглосуточное дежурство - минимум 3 человека будут сидеть и ждать уведомлений от мониторинга и раздавать указания что делать и чинить.
Но если сделать удаленный доступ (openvpn/ssh?) к аптекам, то хотя бы проблемы с софтом можно будет решать без выезда. Но тут тоже будут проблемы - удаленный доступ постоянно будет ломаться - то интернет сгниет, то местные специалисты чуши наделают, то антивирусы с файрволлами с ума сойдут.

Первое, что надо делать товарищу Диме: это понять, зачем вообще нужен его отдел :)
Какие проблемы организации решает ИТ-служба, и как она помогает зарабатывать деньги?
А самое главное - какие не решает (а должна) и в чём может ещё помочь (но пока не помогает)?

И фоном - документировать всё as is.


Понимая ответы на первых два вопроса, можно планировать to be, а имея документированную текущую ситуацию - строить планы мероприятий по переходу от существующей инфраструктуры к перспективной.

Иначе это будет в лучшем случае безвредная ИБД с пожиранием денег организации :-)

  • 1
?

Log in

No account? Create an account