Pull to refresh

Comments 18

Я давно хотел попробовать оффлоадить на фриланс всякую левую фигню, типа «переустановить линух на лабораторной машине через pxe'шную менюшку» (работа тривиальная, но требует времени на ожидание всех этих бесконечных ожиданий биосов).

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

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

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

Вот звонят вам недоумевающие клиенты с вопросом «а что у нас ничего не работает», и вот вы за два часа…

А первые размышления в интернете по вопросу появляются через три часа, а VMWare существование проблемы признаёт к 8 утра, а рекомендацию по временному устранению (пока патчат) делает к 10.

И? Где 2 часа?
наверно в договоре указан такой форс мажор, я не юрист, я инженер.
Вы же своему сотруднику не урежете премию за такой инцидент, так как виноват вообщем то поставщик.

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

Я согласен про бизнес-критикал задачи и оутсорс, те если вы провайдер предоставляющие сервисы на вСфере, то ее должен обслуживать ваш штатный персонал.
Если вы завод по выштамповке запчастей, а на вСфере крутится бухгалтерия, складские системы и взаимодействие с поставщиками-покупателями — почему бы не съэкономить и не отдать ее обслуживание на аутсорс…
Я это привёл уже даже не в пику аутсорсу, а в пример того, что всякие рассказы про «устраняем в течение двух часов» — это лишь best efforts, не более.
VMWare — это вендор ПО, а не аутсорсер.
Вендор коробочного ПО не может и не будет обеспечивать работоспособность конкретной производственной среды покупателя ПО, особенно за стоимость лицензий этого коробочного ПО.

Если инцидент вызван подобной ошибкой в коробочном ПО, то тут и штатные сотрудники и аутсорсеры оказываются в одинаковой ситуации. Но насколько часто такие инциденты происходят?

Но регулярно случаются ситуации на порядки более частые и при этом такие же по уровню отрицательного влияния, когда инцидент может быть решён без вендора, и профессиональный аутсорсер хорошо снижает и простой и подобные риски и заказчику не надо «изобретать велосипед» и тратить время и внимание на организацию всего этого.
Amarao, а можно чуть больше деталей по данному инциденту? Я могу предположить пару сценариев подобного сбоя, но все они не связаны с качеством продукта. Если действительно существует настолько серьезная проблема в работе Vmware, то хотелось бы получить о ней больше информации.
Это было один раз и очень очень давно (2007-). Бага давно поправлена, а версии уж сто лет не актуальны. Я сейчас погуглил, не нашёл источников. Я это говорил не в контексте «аутсорс VS in-house», а в контексте «исправить за два часа».
В контексте «исправить за два часа» — это возможно только если в компании был проведен анализ рисков и спланированы мероприятия на случай их возникновения. Когда ты знаешь, что любые проблемы с гипервизорами ты можешь решить переустановив их за 30 минут, можно гарантировать клиенту восстановление за 2 часа. Если же анализа рисков не проведено, инструкции по аварийному восстановлению не составлены, то ни о каких гарантиях речи не идет, конечно.

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

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

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

Критичность бизнес-процессов каждый определяет для себя сам. Кто-то не аутсорсит даже уборку территории, в то время как другие, желая добиться максимальной эффективности и конкурентоспособности, аутсорсят ит-функцию практически полностью. Например, ведущие мировые банки.
Насчёт «штрафов, которые покрывают простои бизнеса» — ни разу таких не видел. Большие штрафы — видел. Компенсацию убытков (недополученной прибыли) — ни разу. Слишком разорительно и слишком легко эксплуатируемо.
Ну если не полностью покрывают, то точно не позволяют расслабиться и нарушать сроки.
1) Нельзя выбирать одного аутсорсера. Всегда необходим основной и резервный поставщик услуг, особенно в российских реалиях.

2) Заказчик обязан (а не может) привлекать аутсорсера в вопросах проектирования и развития архитектуры. Если этого не происходит, то аутсорсер не может контролировать объем задач по поддержке (заказчик может плохо спроектировать систему), а значит, не может предложить адекватного ценообразования своих услуг. Ни о какой синергии в этом случае также речи не идет.

3) «Ключевой показатель для решения о заключении контракта – Service Level Agreement (соглашение об уровне предоставления услуг)» — как по мне, дак это понятность для обоих сторон (на всех уровнях) что и как будет делаться, а что делаться не будет, а не возвышенная терминология.
Я работаю в компании ICL, но мнение частное.

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

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

Суть SLA вы уловили. Главное, чтоб «что, кому, в какие сроки и с каким качеством» было зафиксировано в максимально измеримом виде.
А чтоб «в случае чего» не случалось, выбирать лучших

Что такое лучший аутсорсер? Есть какое-то универсальное мерило?
Универсально-лучшего нет.

Заказчик должен составить для себя список ключевых требований к аутсорсеру с приоритетами. Например,
— «Решает индиценты быстрее других» — 10 баллов макс
— «Цена» — 8 баллов макс
— «Обязательное наличие подтвержденного опыта с похожими заказчиками» — 10 баллов
— «Кол-во сертифицированных инженеров в каком-то домене» — 7 баллов
и т.п.

Прогнать по списку все возможные кандидатуры и выбрать лучшего.
Only those users with full accounts are able to leave comments. Log in, please.