Лично строил под ITIL процесс сопровождения перерабатывающего предприятия не только в IT и КИПиА, но еще и работу персонала, обслуживающего установки и коммуникации (трубы, запорная арматура и т.д.): сварщиков, механиков, слесарей-ремонтников, ну и бэк сервисы (АХО, HR). Главный инженер и рук.эксплуатации были удивлены, что это возможно и какие результаты может дать.
Так что, поверьте, ITIL в парикмахерской — это реальнее реального, но парикмахерская — сам по себе не самый удачный пример :)
На моем опыте, реален — из эникейщика, но там был не прям вот скачок, пришлось промежуточную менеджерскую ступеньку все-таки пройти, но это было быстро :)
Предлагаю к рассмотрению такой спойлер: Потом окажется, что за рулем бензовоза был Сергей, а события происходят через 10 лет после его кардинальной смены работы… )
Границы все же есть, соглашусь с Mikhael1979. Например, границы разумного :)
Сам проходил и самостоятельное сопровождение компании на 150-200 рабочих мест, и организацию саппорта в качестве руководителя ИТ-поддержки в компании на 3000+ рабочих мест. Сравнивать есть с чем. Четкой границы нет, нужно смотреть и на характер и сферу бизнеса, стоимость тех или иных простоев для него, и на уровень автоматизации и используемых для этого решений — факторов на самом деле много.
И если Ваш пример реален, то это действительно абсурдное решение, или просто кто-то решил «поиграться» в ITIL. К сожалению, много кто не может рассчитать границы эффективности применения методологий и подходов в саппорте. А потом получаются вот такие ИТ-отделы, где на самом деле и 2 эникейщика-то уже нужны только лишь для того, чтобы в отпуск или болезнь одного из них работа не встала.
Ну, s4b в этом плане не самый удачный по управляемости вариант, у него нет возможности большую часть настроек железно задать в принципе. Но стоит учесть прежде всего то, что изначально (когда еще назывался Office Communicator) это был продукт, дополняющий стек Outlook + Exchange, и сейчас таковым является, ничего не изменилось в его концепции. Я это к тому, что расписание статусов ему нужно отправлять в виде события в календаре на Exch, и это единственный правильно идеологический вариант всей указанной выше связки MS, да и по логике time management тоже :)
Но это все лирика. При разрешенном удаленном вызове процедур доступ к реестру не самое большое зло. Посмотрите лучше, что можно натворить при помощи psexec, знания командной строки, в умелых да и не очень руках.
Зачем открывать удаленный доступ по RPC и создавать очень серьезную дыру в безопасности в виде возможности удаленно редактировать реестр? Всем реестром можно управлять при помощи GP, о которых в статье и идет речь, а если каким параметром реестра и нельзя будет по умолчанию управлять, то создается свой шаблон GP — и уже можно.
Своеобразный подход к поиску руководителя целого отдела. Вот например, мне известно что такое DNS, DHCP и для чего они нужны, но я в упор не помню ни их порты, ни их протоколы, знаю, что такое IP-адрес и маска и умею в уме раскладывать по двоичным октетам все это дело, но не держу этот навык наготове в голове каждую секунду. Как не держу в голове и другие технически детали. Мне, как руководителю, достаточно знать для чего существует та или иная технология, информационная система, «волшебная загадочная железка», какие задачи с их помощь можно решить, какой профит от использования всего этого получит бизнес. А уже для понимания, на каких протоколах, по каким портам, с какими библиотеками и т.д. все это работает — для всего этого у меня уже есть именно технари. Это уже их знания, их хлеб, их интерес и т.д. Я эти знания смогу проверить, прочитав техническую документацию и т.д. И мое мнение, что руководитель ИТ отдела все-таки должен обеспечивать взаимодействие ИТ с бизнесом и в интересах бизнеса, обеспечивать условия работы своим технарям, координировать их работу, ставить задачи и определять их приоритет так, чтобы повысить эффективность ИТ в решении задач бизнеса и дать бизнесу инструменты по более эффективной генерации прибыли, но никак не копать протоколы и железки.
Я отношусь именно к такому типу руководителей. У меня есть шанс при таком раскладе и указанному выше подходу пройти ваше собеседование на должность начальника
ИТ одела? :)
Так что, поверьте, ITIL в парикмахерской — это реальнее реального, но парикмахерская — сам по себе не самый удачный пример :)
Сам проходил и самостоятельное сопровождение компании на 150-200 рабочих мест, и организацию саппорта в качестве руководителя ИТ-поддержки в компании на 3000+ рабочих мест. Сравнивать есть с чем. Четкой границы нет, нужно смотреть и на характер и сферу бизнеса, стоимость тех или иных простоев для него, и на уровень автоматизации и используемых для этого решений — факторов на самом деле много.
И если Ваш пример реален, то это действительно абсурдное решение, или просто кто-то решил «поиграться» в ITIL. К сожалению, много кто не может рассчитать границы эффективности применения методологий и подходов в саппорте. А потом получаются вот такие ИТ-отделы, где на самом деле и 2 эникейщика-то уже нужны только лишь для того, чтобы в отпуск или болезнь одного из них работа не встала.
Но это все лирика. При разрешенном удаленном вызове процедур доступ к реестру не самое большое зло. Посмотрите лучше, что можно натворить при помощи psexec, знания командной строки, в умелых да и не очень руках.
Я отношусь именно к такому типу руководителей. У меня есть шанс при таком раскладе и указанному выше подходу пройти ваше собеседование на должность начальника
ИТ одела? :)