Pull to refresh

Comments 56

вводить такое сразу — ад.
дорасти до такого — достижение.
реализовать такое — крутизна.

молодцы!
Спасибо. У вас двумя первыми строчками получилось донести то, о чём мы спорили в прошлом топике. Да, многие вещи вводить сразу — тотальный кошмар, и нужно сначала пройти пару «линек» до них.
Большинство остаётся на одной из предыдущих ступеней :)
(чисто формально) По КЗОТу штрафы запрещены. Даже если они маскируются в виде «половина зарплаты выдаётся премией».
Штраф — очень пользовательский термин. Скажем так, недобонус. И это, КЗОТ — он про сотрудников. Тут речь про оплату контрагента.
Ну вот если «недобонус» вычитается из обычно оплачиваемой части, то человек с лёгкостью выиграет в суде, если покажет, что в компании общепринято платить пол-зарплаты премией.

Простые доказательства:
* История зарплат, где ежемесячно «премия» примерно одинакового размера
* Объявления о вакансиях, где в качестве ЗП называется сумма с премией
* Свидетельства сотрудников (парочку среди оштрафованных человек легко найдёт)
Вы точно поняли, что это про контрагента-юрлицо?
Я точно понял, что это про сотрудников этого конагента-юрлица. Или вы выплачиваете «бонусы» юрлицам?
Мы к сотрудникам этого юрлица не имеем никакого отношения. Сумма оплаты по договору в месяц зависит от эффективности работы контрагента, исполнения KPI, если угодно. Стало понятнее?
А, ок. Юрики между собой могут любые условия изобретать.
Сейчас уточню в топике, почему это важно, спасибо.
Поясните, пожалуйста:
•В пик сезона — должен лежать преднастроенный системный блок, который нужно просто переподключить.
•В остальное время — SLA 4 часа на восстановление работы этого узла в базе данных.
Вы что, после сезона их выкидываете?
Они концентрируются обратно у контрагента, как правило. Пик бывает не только у нас, но и у других его клиентов, иногда — в противофазе, летом.
Кроме того, эти же машины и лицензии используются для развёртывания других отделов в пик разработки, например.
Т.е. у Вас железо (частично) не принадлежит Вам?
Резервное — не уверен, боевое — точно наше. Вообще, если можно арендовать что-то на время или вернуть — мы воспользуемся из-за неравномерного характера продаж.
А если ломается железка, вместо неё дают не Вашу, а арендованную, что происходит с Вашей?
Если резервное Ваше — какого хрена его отдают другим клиента Вашего контрагента???
Я к тому, что при замене она может становиться нашей.
Наша чинится и отправляется на наш склад. Когда потребуется — вводится в строй или встаёт в резерв.
Много у вас на складе оборудования «пылится»?
Не очень, мы же постоянно расширяемся. Но, чувствую, вопрос ещё встанет.
Так-то в этом самая суть «облачных» технологий.
Не что-то где-то там в сети.
А нужный ресурс, к которому можно при надобности добавлять ещё такой же. А при ненадобности — отключать.
В пик сезона системник меняется как только использовался.
Вне пика сезона — можно неделю и потерпеть с созданием резервного системника
Правильные вещи излагаете. Жду продолжения.
Спасибо!
Да, продолжение нужно. Интересны не только «приключения» но и «выводы».
Ну что, рассказывать дальше наши приключения, или ну его нафиг, эту IT-инфраструктуру среднего бизнеса, которая и так всем знакома?


Очень интересно! Пожалуйста, продолжайте и, если не сложно, осветите следующие вопросы:

1) Как организована работа над повышением качества работы ИТ-инфраструктуры? Сейчас вы описали, как ваши аутсорсеры исправно лечат аварии, а что (и как) они делают, чтобы число аварий уменьшалось со временем? В их ли интересах вообще уменьшать количество аварий или нет?

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

3) Кто первая линия технической поддержки? Т.е. кто принимает звонок от пользователя и ведет учет времени обращения, реакции и устранения инцидента? Если это делает аутсорсер, то как вы верифицируете правильность предоставляемого им отчета?

4) Что делается для того, чтобы SLA не нарушался? Т.е. какие мероприятия вы проводите совместно с поставщиком, чтобы убедиться, что не возникнет ситуаций, при которых поставщик не сможет восстановить сервис в рамках SLA? Т.к. если такие ситуации возможны, то потенциальные штрафы по ним ложатся в себестоимость договора.

5) У вас много региональных магазинов. Как организована их поддержка на местах?

6) Есть ли какие-то рычаги влияния у ИТ-аутсорсера на ваш ИТ-отдел или на решения в компании? Из вашей статьи следует, что вы загнали аутсорсера в достаточно бесправное положение и тем самым прекратили «футбол». Может ли аутсорсер как-то повлиять на вас по договору, если, к примеру, вы не хотите заменить старый и регулярно зависающий (и генерящий тикеты) сервер? Т.е. понятно, что у вас достаточно теплые отношения с вашим поставщиком, но хотелось бы понимать, как это тепло перенесено на строки договора.

7) «Перечисление сервисов занимает порядка 30 страниц» — это нечто подобное habrahabr.ru/company/croc/blog/187124/ или построенное на других принципах? Требует ли данный каталог от клиента наличия специалиста, понимающего все тонкости ИТ-технологий? Буду признателен, если вы осветите эту тему подробнее.

Спасибо!
Сейчас многое решается благодаря тому, что мы уже давно сработались. По практике — спасибо, вопросы отличные, расскажу про опыт и случаи позже.
Тоже интересует первый пункт, особенно со стороны аутсорсера. По опыту знаю, что, чем лучше я сделаю свою работу, тем мне же хуже. Возникнет какая-нибудь надобность в моих услугах через год (недавний случай), но целый год я с этой организации не имею никакого дохода, а кушать хочется немного чаще :(
Так оплата-то за работающий сервис помесячно, а не за ремонты.
Ой… а ведь правда. Но мне от этого не легче, сложно сподвигнуть заказчиков пойти на основу с абонентской платой, да еще и оформлять это надо и всё такое (а я это страсть, как не люблю, прям на физическом уровне).
Вопрос того, как вы и заказчики умеете считать, пожалуй. Если бизнес-планирование не развито — не уговорите.
Это и обидно, считать умеют, планы есть, но (вездесущее но) на короткий срок.
Судя по тому, что написано в статье мотивация заказчиков видна насквозь. Даже пример где сутки простоя — три месяца бесплатного обслуживания.
Мне казалось это мотивация исполнителя, а не заказчика :)
Мотивация для перехода на такую систему. Заказчик получает гарантии.
Хм… Спасибо за идею, в таком ключе я и не думал.
К сожалению, чтобы не стоят перед выбором отремонтировать хорошо или отремонтировать плохо, нужно в принципе отказаться от разовых ремонтов. Разовые ремонты — это для сервисных центров, а не для ИТ-аутсорсеров. Сегодня вы клиенту почините его сервер на разовой основе, а через полгода у него развалится рейд и не окажется бекапов (т.к. никто не проверял ни первого, ни второго) — чем вы сможете ему помочь тогда?
Да не стою я перед выбором, тупо всегда делаю максимально качественно, рассказывая клиенту о плюсах минусах, о том что может случиться в таких-то ситуациях, затем кратко резюмирую, перечисляя критичные и не очень вещи, описываю, что и в каких случаях он может потерять и называю цену и время необходимое для устранения, часто клиент соглашается потратить сегодня чуть больше воизбежание, но не всегда.

> чем вы сможете ему помочь тогда?
эм… пачиню? :)

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

> с ними проще не работать.
Я не настолько загружен, чтобы отказываться от заработка.
Заградительные цены это единственный вариант, если мы конечно не говорим про физиков и конторки меньше 5 машин, там не поможет.
Первый ремонт может быть дешев и рекомендации это хорошо, но надо не забыть упомянуть что если случится что-то в следующий раз, то тариф будет в разы больше.
но как правило, клиент после 1-2-3 раза очень задумается стоит ли дальше с вами иметь дело.
Именно поэтому, а так же потому что мне это претит, я не делаю плохо, лучше посоветую того, кто сделает это лучше. Кроме редких случаев, когда делаю только на ту сумму, которую получу (бывает, что клиент просто не хочет или еще по каким-то причинам, не готов заплатить больше), но даже в этих, редких случаях, предупреждаю о возможных последствиях.
Скажи пожалуйста, почему ты публикуешь статьи на хабре в наименее «популярное» время? Чтобы снизить конкуренцию за внимание читателя?
В воскресенье вечером у меня обычно есть время, а на Хабре 6-7 топиков за день.
Спасибо за интересную тему. Я как раз немного сейчас занимаюсь оргнизацией сапорта. И в связи с этим есть вопросы.

Судя по статье выполнение СЛА и штрафы расчитывает сам аутсорсер. Делается ли это и на стороне вашей компании, для контроля, или вы верите безоговорочно?
Были ли ситуации когда то что насчитал аутсорсер не совпадало с вашим мнением и как такие ситуации решались/решаются системно?
Общий принцип — мы всем верим, но не создаём ситуации, когда злоупотребить доверием легче, чем сделать правильно. В моменты внедрения точно тикеты ставились параллельно на наш IT-отдел и аутсорс, аутсорс закрывал — по факту оценивался срок. Сейчас есть какая-то автоматизация на стороне аутсорса, но точно не скажу. Спасибо, вопрос добавляю к серии выше, покопаюсь и расскажу позже.
Интересно какой процент аутсорсеров, сказал бы, что вы кошмар, а не клиент, а какой — мечта, а не клиент?
Я бы сказал, 50/50. Потому что мы с Вовой довольно долго, частно и много обсуждали, как лучше сделать: в текущей ситуации много вклада со стороны как нас, так и его. Повторюсь, пришлось постоять на его месте, чтобы понять некоторые вещи.
Если вы и с другими поставщиками будете готовы также обсуждать и прорабатывать процессы, то вы для всех будете клиентом мечты :)

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

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


Т.е. людей может быть настолько много, что они увидят огромную очередь в первую кассу, развернутся и уйдут? Речь вроде не про пиковые нагрузки на магазин шла в том абзаце…
Могут уйти. Могут просто запомнить, что тут очереди. Это и прямые потери при загрузке выше средней, и репутационные (косвенные). Но оценивать их для аутсорсера не имеет смысла, оценивается только сервис исходя из стоимости его поддержания.
А как вы считаете, смогли бы договориться на такую модель аутсорсинга со сторонней компанией? Тут всё таки личный фактор бывшего сотрудника сыграл.
Думаю далеко не с каждой, но в целом реально. Я полагаю, что клиент для аутсорса относительно крупный, деньги хорошие, так просто отказываться не захочет никто. Но многие аутсорсеры просто не захотели бы заморачиваться. Зачем, если есть много других клиентов, которых можно «разводить» на услуги получая деньги с меньшей ответственностью?
Снимаю шляпу и перед вами и перед вашими исполнителями! Верное дело делаете!
Only those users with full accounts are able to leave comments. Log in, please.