Comments 15
Спасибо за реальный пример. Про TOC написано много статей, есть на Хабре даже любители пописать рассказы на эту тему. Однако, реальные примеры разбирают не так уж и часто. Сам недавно дочитал «Цель» Голдратта. У меня осталось некоторое противоречивое чувство, что он ставил этот подход в пику «массовому производству», когда стремились за уменьшением себестоимости единицы товара, но на этом фоне потеряли (сильно отложили во времени) операционные прибыли. Еще раз — спасибо за реальный пример.
Автор слегка замешивает две слегка несовместимых техподдержки в своей статье.
Техподдержка продукта и техподдержка внутреннего ИТ компании.
Там вообще разные подходы, цели и ценности. А в статье это все намешано, поэтому на выходе автор борется с проблемами методами решения для других проблем.
Поэтому все описанное в этой статье не будет работать.
Для внутреннего ИТ вас будут утилизировать на 100% и это норма, поскольку так Бизнесу выгоднее. Критичные задачи которые могут привести к простою бизнеса вы в любом случае будете решать в первую очередь. Рутину вы будете делать пока нет пожаров и потопов. Так что отдел будут отжимать по людям и деньгам по максимуму. Ровно настолько что бы барахталось и при этому не дышали слишком свободно, иначе это не оптимальные затраты на то, что не приносит денег.
С поддержкой продукта выпускаемого компанией и проще и сложнее одновременно — проще потому что проблемы знакомы и наверняка описаны. На каждый глюк есть workflow решения с которым справится даже обезьяна, если её посадить на первую линию. Именно поэтому часто первую линию аутсорсят индусам — они умнее обезьян, а стоят столько же. Сложнее, потому что больше упор на качество и скорость разработки. Именно по этому так все топят за микросервисы — зачем нам техсуппорты, когда мы в течение дня можем пофиксить проблему и выкатить на прод решение. По первому пути идут те кто не может (например, операторы (провайдеры) связи для конечных потребителей, что бы им бабушки звонили), по второму те кто выкатывает продукт как сервис в мир интернетов.
ЗЫю
Картинки на которых вы закрываете текст белыми квадратами — одно из ужаснейших проявлений редактуры статьи. Прям фу фу так делать.
Техподдержка продукта и техподдержка внутреннего ИТ компании.
Руководство считает, что ресурсы надо утилизировать на 100%, чтобы они не простаивали. Поэтому и загружает админа задачами. Но на самом деле это заблуждение, вызывающее огромные проблемы.Это техподдержка внутренного ИТ компании.
Решить проблему можно. Теория ограничений для этого случая говорит:Это техподдержка продукта продаваемого компанией.
· Расширьте бутылочное горлышко
· Подчините ему всё производство
Там вообще разные подходы, цели и ценности. А в статье это все намешано, поэтому на выходе автор борется с проблемами методами решения для других проблем.
Поэтому все описанное в этой статье не будет работать.
Для внутреннего ИТ вас будут утилизировать на 100% и это норма, поскольку так Бизнесу выгоднее. Критичные задачи которые могут привести к простою бизнеса вы в любом случае будете решать в первую очередь. Рутину вы будете делать пока нет пожаров и потопов. Так что отдел будут отжимать по людям и деньгам по максимуму. Ровно настолько что бы барахталось и при этому не дышали слишком свободно, иначе это не оптимальные затраты на то, что не приносит денег.
С поддержкой продукта выпускаемого компанией и проще и сложнее одновременно — проще потому что проблемы знакомы и наверняка описаны. На каждый глюк есть workflow решения с которым справится даже обезьяна, если её посадить на первую линию. Именно поэтому часто первую линию аутсорсят индусам — они умнее обезьян, а стоят столько же. Сложнее, потому что больше упор на качество и скорость разработки. Именно по этому так все топят за микросервисы — зачем нам техсуппорты, когда мы в течение дня можем пофиксить проблему и выкатить на прод решение. По первому пути идут те кто не может (например, операторы (провайдеры) связи для конечных потребителей, что бы им бабушки звонили), по второму те кто выкатывает продукт как сервис в мир интернетов.
ЗЫю
Картинки на которых вы закрываете текст белыми квадратами — одно из ужаснейших проявлений редактуры статьи. Прям фу фу так делать.
Для внутреннего ИТ вас будут утилизировать на 100% и это норма, поскольку так Бизнесу выгоднее.
Очень жалко, что я не убедил Вас, что это не так.
Критичные задачи которые могут привести к простою бизнеса
Это типичное возражение, основанное на неподтвержденных данных. В Toyota Production System есть даже специальное понятие — андон.
www.up-pro.ru/encyclopedia/andon.html
Полная остановка всего конвейера в случае обнаружения брака или критической ситуации, наоборот, гораздо более выгодна (по деньгам) для компании, чем перепроизводство.
Анализ результатов внедрений полной остановки и простоя бизнеса говорит о том, что компания получает от этого больше прибыль, чем от беспрерывной работы.
Теории Ограничений также говорит, что остановка необходима.
В общем, в комментарии трудно объяснить тему, про которую написана не одна книга. Если интересно, могу порекомендовать прочитать книги Дао Тойота (в 2-х томах), Цель (основы Теории Ограничений), Цель-2 (о том как анализировать процессы производства)
Очень жалко, что я не убедил Вас, что это не так.Меня не нужно убеждать :) я же не Бизнес. Несмотря на то, что я не топовый руководитель в организации, я остаюсь наемным работником и не хотел бы что бы меня утилизировали на 100%, просто потому что не будет времени на саморазвитие или вылизывание каких то рабочих процессов.
Это типичное возражение, основанное на неподтвержденных данных.Я понимаю Ваше желание как то формализовать решение проблем с узкими местами в процессах. Найти своеобразный философский камень. Универсальную формулу для решения любых проблем. Вы уходите в прекрасную теорию о которой мы все в глубине души мечтаем. Красивые метрики, правильные KPI, образованные пользователи, идеально наполненная CMDB, проактивный мониторинг и оркестрация. Но углубляясь в теорию Вы неизбежно отрываетесь от земли. А на земле, тут в грязи, остается еще много людей и работы. Я делился своими наблюдениями в контексте той работы и ситуации которая вокруг меня. Я не работаю в международной корпорации с их корпоративной магией по одному админу на тысячи человек, но и пользователей под обслуживанием моей и смежных команд не одна тысяча. Я и есть тот человек, который внедряет сервисдески в организациях и переводит ИТ компании от исключительно внутренней ИТ команды, до частичного или полного ИТ аутсорсинга. Я очень часто настраиваю процессы взаимодействия, которые потом спускаются до команд и групп отвечающих за свою часть общего дела что бы ИТ работало быстрее. Работаю что бы Бизнес не простаивал, когда в этом нет необходимости.
Я здесь на передовой, в окопах. В теории практика и теория не отличаются, но вот на практике…
В теории практика и теория не отличаются, но вот на практике…
Дело в том, что Бережливое производство — это уже давно практика.
Проблема в том, что у людей есть убеждения и эти убеждения довольно трудно изменить. Если я представлю Вам доказательства обратного, то Вы все равно мне не поверите :-) Конечно, у Вас нет оснований мне верить. Вы видите окружающую реальность, которая убеждает Вас, что другие альтернативы не работают.
И у Вас и у меня одна цель — с помощью сервис деска позволить компаниям отработать все обращениями клиентов в срок. Но Вы делаете это своим способом, а я своим. В основе наших действий лежат некие причины, правила или убеждения, не позволяющие нам согласиться друг с другом.
Но на самом деле, если рассмотреть первопричины этих убеждений, оказывается, что можно выработать общее решение, устраняющее первопричину конфликтной ситуации.
Вы навели меня на мысль написать статью на эту тему и разобрать пример с сервис деском и простоями ресурсов.
Я обдумал Ваши слова и понимаю, что они основаны на опыте, поэтому предыдущие свои ответы сейчас считаю некорректными.
Можете поделится почему Вы считаете, что для внутреннего ИТ утилизация на 100% отдела поддержки выгодна бизнесу?
Ответ на этот вопрос одновременно и простой, и одновременно сложный.
Сложный ответ я спрятал под спойлер просто потому что там буквально простыня текста с прелюдией, завязкой и заезженным сюжетом и без счастливого конца в корейском стиле.
А простой ответ: Невозможно обеспечить не 100% нагрузку на ИТ специалистов, если Вы нанимаете обычных (не ИТ) сотрудников с низкими общими компетенциями. Либо вы необоснованно раздуваете штат ИТшников, как и затраты на их ФОТ и получаете не 100% нагрузку на ИТ отдел, либо миритесь с 100% нагрузкой на ИТшников закрывая глаза на их мелкие факапы.
Сложный ответ я спрятал под спойлер просто потому что там буквально простыня текста с прелюдией, завязкой и заезженным сюжетом и без счастливого конца в корейском стиле.
А простой ответ: Невозможно обеспечить не 100% нагрузку на ИТ специалистов, если Вы нанимаете обычных (не ИТ) сотрудников с низкими общими компетенциями. Либо вы необоснованно раздуваете штат ИТшников, как и затраты на их ФОТ и получаете не 100% нагрузку на ИТ отдел, либо миритесь с 100% нагрузкой на ИТшников закрывая глаза на их мелкие факапы.
Сложный ответ
Я сразу оговорюсь, что разговор идет не о компаниях в которых ИТ является доходной частью как разрабочики какого либо ИТ продукта или сервиса. Ибо, здесь, на Хабре, статей о таких компаниях и их процессах доминирующее большинство, нежели чем о процессах ИТ, которые являются поддерживающими для основного бизнеса (даже если бизнес без этой поддержки не возможен, и даже если такая правильная поддержка дает некое конкурентное преимущество).
Я думаю, мы все понимаем, что у Бизнеса тоже есть стадии зрелости. Причем, как бы это парадоксально не звучало, даже внутри компании/группы компаний эта самая зрелость может различаться от места к месту несмотря на наличие одного управляющего центра и пачки общекорпоративных стандартов. Все сильно зависит региона нашей необъятной страны, общего уровня компетенций обыкновенных (не ИТ) сотрудников, насколько они знают и могут применять свои права прописанные в ТК РФ, да и вообще их адекватности и отношения к работе. А так же сколько полномочий и возможностей у СБ компании.
Вернемся к ИТ отделу. Если грубо, то его работа состоит из проектных работ, плановых задач обслуживания, исполнения запросов пользователей и инцидентов. Все вместе они формируют нагрузку на ИТ отдел выраженный в отношении к обеденному часу в конкретной организации. Если Вы в 13:02 уже не можете дозвониться до любого ИТ специалиста, потому что у него начался обед — значит ИТ отдел нагружен на 100%, и не важно что вы там видите в журнале работ сервисдеска или показателях SLA/KPI.
Итак. Бизнес (собственники) хочет(ят) что бы бабло зарабатывалось. Для этого нужно что бы вертелись производственные процессы, клиенты обслуживались, бухгалтерия считала и отчеты в нужные инспекции подавала вовремя, а учетная система была доступна и не висела колом.
Еще у нас есть финдир, задача которого снизить расходную часть, и повысить доходную. А еще Бизнес почти всегда считает любого (не входящего в ТОП руководителей) сотрудника ресурсом, а не ценностью. А как мы все знаем, ресурс нужно вырабатывать на 100% для максимизации доходов.
Как я уже говорил, нагрузка на ИТ грубо зависит от четырех типов работ, из которых вторая половина слабо прогнозируема, а последняя четверть почти непрогнозируемо внезапна и может генерировать от 0% до 100% загрузки ИТ отдела в любой, рэндомный момент времени. В кратком описании я сказал, что невозможно обеспечить не 100% нагрузку на ИТ отдел, если остальные сотрудники — тупые пробки умеющие вертеть только ручку станка для которого их и взяли на эту работу.
Бизнес берет на работу условного бухгалтера, его собеседуют, понимают что от может отличить дебит от кредита и знает план счетов, знает куда и что тыкать в 1Ске. Его принимают на работу и… свежепришедший сотрудник сидит и ждет, когда ему настроят рабочий ПК, хотя в его телефоне в СМС уже висят реквизиты для первичного входя в систему, а сам ПК как стоял после прошлого сотрудника под столом, так и продолжает стоять. И даже попав в систему он просит настоить ему почту, наглухо игнорируя автонастройку Outlook при работе с Exchange. Он просто не пытается даже это сделать, генерируя простой в своей работе и инцидент для техподдержки что бы решить эту проблему. И приветственные письма с подсказками и инструкциями он тоже читает жопой. И последующие проблемы сотрудник с низкой социальной компетенцией так же продолжает отправлять в техподдержку, оттуда к нему подключатся и нажмут нужную кнопку. Или вежливо скажут, где он в какое поле неправильные данные ввел. Или прочитают ошибку с его экрана и скажут, правильнее на «Да» или «Нет» нажать. И их всегда можно обвинить в своем простое.
Больше сотрудников с низкой социальной компетенцией = больше тупых заявок = больше сотрудников техподдержки (читай «сотрудников ИТ отдела») требуется что бы рабочие процессы бизнеса вертелись.
Но готов ли Бизнес бесконечно увеличивать количество сотрудников ИТ отдела? — Нет, не готов. Просто потому что от этого растет ФОТ и уменьшается загрузка ИТ специалистов, а это снижает доходную часть работы компании, а еще ресурс начинает использоваться не на 100% — а это возмутительно и неправильно. Поэтому ищется баланс: ИТ сотрудник загружен на 100%, при этом тупые пользователи расплачиваются это неоплачиваемыми переработками.
А что если нанять сотрудников с нормальной общей базовой компетентностью? Тоже — нет. Они дороже, они лучше знают ТК и менее склонны выходить забесплатно поработать в выходные, даже если причина не в простоях по ИТ задачам (например отчетные периоды, производственный кранч, эпидемиалогическая ситуация). Причем, обычно, эти затраты куда больше чем ФОТ на лишних ИТ спецов. А иногда, банально, таких людей нет. Найти диспетчера на развесовку вагонов в карьер в ебенях за 15-20к рублей, который сможет попинговав шлюз понять проблема в канале связи или в выпавшем проводе из компа — почти нереально.
А в чем ошибка большинства аналитиков, консультантов и прочих оптимизаторов ИТ направления приходящих «на помощь» Бизнесу? Их ошибка в том, что они берут ИТ в отрыве от организации. Смотрят в сервисдеск на количество запросов и инцидентов, принимая заявки от тупых сотрудников как должное, неизбежное зло. Пытаются найти узкие места, автоматизировать, оптимизировать, как то перестроить потоки в самом ИТ отделе, говорят об усилении роли мониторинга и оркестрации, о проактивной работе. Говорят, вот у вас тут процессы стоят и отчеты не делаются потому что ИТ долго реагирует — пытаются решить эту проблему через SLA/KPI. И в итоге получают насквозь зарегламентированный и обвешанный метриками ИТ отдел, посреди множества сотрудников других отделов, которые не могут банально прочитать описание ошибки на экране и перезагрузить ПК на всякий случай.
Но Бизнес то все это видит и понимает (возможно не напрямую, но на уровне интуиции финдира). Поэтому, если пипец критические проблемы, решаются в кротчайшие сроки и возникают не слишком часто — 100% нагрузка на ИТ это нормальное и самое дешевое решение.
Все вышесказанное вы не встретите в организациях, где при трудоустройстве вам выдают талмуд регламентов, инструкций и требований, а через месяц проводят внутренний сертификационный экзамен от результатов которого будет зависеть — будете ли вы работать в этой организации, или нет. Как правило в таких организациях зарплата выше рынка, жестко контролируемый SLA и не идиотский KPI. И ИТ не нагруженный на 100%, потому что он решает проблемы бизнеса, а не тупых сотрудников.
Основная, на мой взгляд, ошибка в Вашей статье в том, что вы принимаете за аксиому 100% компетентность сотрудников в профильной и их достаточную компетентность в смежных областях. В реальности это далеко не так. Поэтому все ваши метрики, теории и ограничения, да и прочие вещи не будут работать. Вернее они будут работать (и применяются) там где в этом нет необходимости. Увидеть что условный админ загружен на 100% и нужен еще один админ вообще не сложно. До причины докапываются вообще не многие. Решать загруженность ИТ отдела повышением компетентности остальных сотрудников — ну я такого лично не видел, как и то, что бы Бизнес корректно считал простои сотрудников от неработающих систем зависящих от ИТ на коротких промежутках времени. Это только в моих влажных мечтах бывает.
Кстати, такая же проблема зачастую встречается не только в ИТ отделе. Компетенции рядовых сотрудников, увы, постоянно снижаются. Требования к ИТ что бы они предусмотрели, за руку подержали, со свечкой рядом постояли — все время только растут.
Я думаю, мы все понимаем, что у Бизнеса тоже есть стадии зрелости. Причем, как бы это парадоксально не звучало, даже внутри компании/группы компаний эта самая зрелость может различаться от места к месту несмотря на наличие одного управляющего центра и пачки общекорпоративных стандартов. Все сильно зависит региона нашей необъятной страны, общего уровня компетенций обыкновенных (не ИТ) сотрудников, насколько они знают и могут применять свои права прописанные в ТК РФ, да и вообще их адекватности и отношения к работе. А так же сколько полномочий и возможностей у СБ компании.
Вернемся к ИТ отделу. Если грубо, то его работа состоит из проектных работ, плановых задач обслуживания, исполнения запросов пользователей и инцидентов. Все вместе они формируют нагрузку на ИТ отдел выраженный в отношении к обеденному часу в конкретной организации. Если Вы в 13:02 уже не можете дозвониться до любого ИТ специалиста, потому что у него начался обед — значит ИТ отдел нагружен на 100%, и не важно что вы там видите в журнале работ сервисдеска или показателях SLA/KPI.
Итак. Бизнес (собственники) хочет(ят) что бы бабло зарабатывалось. Для этого нужно что бы вертелись производственные процессы, клиенты обслуживались, бухгалтерия считала и отчеты в нужные инспекции подавала вовремя, а учетная система была доступна и не висела колом.
Еще у нас есть финдир, задача которого снизить расходную часть, и повысить доходную. А еще Бизнес почти всегда считает любого (не входящего в ТОП руководителей) сотрудника ресурсом, а не ценностью. А как мы все знаем, ресурс нужно вырабатывать на 100% для максимизации доходов.
Как я уже говорил, нагрузка на ИТ грубо зависит от четырех типов работ, из которых вторая половина слабо прогнозируема, а последняя четверть почти непрогнозируемо внезапна и может генерировать от 0% до 100% загрузки ИТ отдела в любой, рэндомный момент времени. В кратком описании я сказал, что невозможно обеспечить не 100% нагрузку на ИТ отдел, если остальные сотрудники — тупые пробки умеющие вертеть только ручку станка для которого их и взяли на эту работу.
Бизнес берет на работу условного бухгалтера, его собеседуют, понимают что от может отличить дебит от кредита и знает план счетов, знает куда и что тыкать в 1Ске. Его принимают на работу и… свежепришедший сотрудник сидит и ждет, когда ему настроят рабочий ПК, хотя в его телефоне в СМС уже висят реквизиты для первичного входя в систему, а сам ПК как стоял после прошлого сотрудника под столом, так и продолжает стоять. И даже попав в систему он просит настоить ему почту, наглухо игнорируя автонастройку Outlook при работе с Exchange. Он просто не пытается даже это сделать, генерируя простой в своей работе и инцидент для техподдержки что бы решить эту проблему. И приветственные письма с подсказками и инструкциями он тоже читает жопой. И последующие проблемы сотрудник с низкой социальной компетенцией так же продолжает отправлять в техподдержку, оттуда к нему подключатся и нажмут нужную кнопку. Или вежливо скажут, где он в какое поле неправильные данные ввел. Или прочитают ошибку с его экрана и скажут, правильнее на «Да» или «Нет» нажать. И их всегда можно обвинить в своем простое.
Больше сотрудников с низкой социальной компетенцией = больше тупых заявок = больше сотрудников техподдержки (читай «сотрудников ИТ отдела») требуется что бы рабочие процессы бизнеса вертелись.
Но готов ли Бизнес бесконечно увеличивать количество сотрудников ИТ отдела? — Нет, не готов. Просто потому что от этого растет ФОТ и уменьшается загрузка ИТ специалистов, а это снижает доходную часть работы компании, а еще ресурс начинает использоваться не на 100% — а это возмутительно и неправильно. Поэтому ищется баланс: ИТ сотрудник загружен на 100%, при этом тупые пользователи расплачиваются это неоплачиваемыми переработками.
А что если нанять сотрудников с нормальной общей базовой компетентностью? Тоже — нет. Они дороже, они лучше знают ТК и менее склонны выходить забесплатно поработать в выходные, даже если причина не в простоях по ИТ задачам (например отчетные периоды, производственный кранч, эпидемиалогическая ситуация). Причем, обычно, эти затраты куда больше чем ФОТ на лишних ИТ спецов. А иногда, банально, таких людей нет. Найти диспетчера на развесовку вагонов в карьер в ебенях за 15-20к рублей, который сможет попинговав шлюз понять проблема в канале связи или в выпавшем проводе из компа — почти нереально.
А в чем ошибка большинства аналитиков, консультантов и прочих оптимизаторов ИТ направления приходящих «на помощь» Бизнесу? Их ошибка в том, что они берут ИТ в отрыве от организации. Смотрят в сервисдеск на количество запросов и инцидентов, принимая заявки от тупых сотрудников как должное, неизбежное зло. Пытаются найти узкие места, автоматизировать, оптимизировать, как то перестроить потоки в самом ИТ отделе, говорят об усилении роли мониторинга и оркестрации, о проактивной работе. Говорят, вот у вас тут процессы стоят и отчеты не делаются потому что ИТ долго реагирует — пытаются решить эту проблему через SLA/KPI. И в итоге получают насквозь зарегламентированный и обвешанный метриками ИТ отдел, посреди множества сотрудников других отделов, которые не могут банально прочитать описание ошибки на экране и перезагрузить ПК на всякий случай.
Но Бизнес то все это видит и понимает (возможно не напрямую, но на уровне интуиции финдира). Поэтому, если пипец критические проблемы, решаются в кротчайшие сроки и возникают не слишком часто — 100% нагрузка на ИТ это нормальное и самое дешевое решение.
Все вышесказанное вы не встретите в организациях, где при трудоустройстве вам выдают талмуд регламентов, инструкций и требований, а через месяц проводят внутренний сертификационный экзамен от результатов которого будет зависеть — будете ли вы работать в этой организации, или нет. Как правило в таких организациях зарплата выше рынка, жестко контролируемый SLA и не идиотский KPI. И ИТ не нагруженный на 100%, потому что он решает проблемы бизнеса, а не тупых сотрудников.
Основная, на мой взгляд, ошибка в Вашей статье в том, что вы принимаете за аксиому 100% компетентность сотрудников в профильной и их достаточную компетентность в смежных областях. В реальности это далеко не так. Поэтому все ваши метрики, теории и ограничения, да и прочие вещи не будут работать. Вернее они будут работать (и применяются) там где в этом нет необходимости. Увидеть что условный админ загружен на 100% и нужен еще один админ вообще не сложно. До причины докапываются вообще не многие. Решать загруженность ИТ отдела повышением компетентности остальных сотрудников — ну я такого лично не видел, как и то, что бы Бизнес корректно считал простои сотрудников от неработающих систем зависящих от ИТ на коротких промежутках времени. Это только в моих влажных мечтах бывает.
Кстати, такая же проблема зачастую встречается не только в ИТ отделе. Компетенции рядовых сотрудников, увы, постоянно снижаются. Требования к ИТ что бы они предусмотрели, за руку подержали, со свечкой рядом постояли — все время только растут.
Если я правильно понял, то Вы считаете, что проблемой является не ИТ-отдел, а потребители — сотрудники других отделов с низкой квалификацией, которые не могут даже минимально напрячь извилины, чтобы просто прочитать сообщение на экране? Все правильно?
А что бы Вы предложили со всем этим делать?
А что бы Вы предложили со всем этим делать?
Ну посудите сами — вычислительные мощности уже не проблема, не хватило своих взял облаков. Софт тоже не проблема, на любой вкус и цвет — выбирай нужное и крути свои процессы. Орды девелоперов готовы накодить все что ты захочешь. Аналитика любая — все сейчас собирают бигдату и вертят её в попытке увидеть в этом месиве закономерность.
Но потом прилетает типичный запрос на срочное решение проблемы (инцидент) от бухгалтера, хорошо хоть с скриншотом:
и понимаете, в описании к заявке нет слов, что в учетной системе с р/с все корректно, и возможно касяк в файле обмена. да фиг с ним с файлом обмена, пускай просто напишет сразу что с Р/С все железобетонно в норме!
Я понимаю, что бухгалтер не полезет в XML/JSON файл смотреть структуру и искать проблемную запись, от него этого никто не требует. Если ошибка есть, то её нужно исправлять в учетной системе в модуле выгрузки — это и есть инцидент который требует участия техподержки/суппортеров учетной системы. Для этого они и есть.
Но заявка исполнится в стиле «ой, а я тут и не заметила что р/с неправильно вбит, кнопка видимо заела». А я, как руководитель, скромно помещу в бэклог вопрос с привязкой к заявке, почему модуль выгрузки не проверяет эту корректность сам до выгрузки файла и было бы неплохо реализовать и чекнуть мож там накопилось чего, и почему бухгалтер не делает выгрузку на сайт фонд соцстраха напрямую, а через файл обмена. Мне когда-нибудь замученные разработчики учетной системы ответят что из коропки этого функционала нет, а конфу они менять не будут, потому что она слетит с поддержки.
Я не могу понять, почему в сервисдесках можно оценить работу специалиста, но нельзя оценить заявку от пользователя. Клиент всегда прав? Но клиент/сотрудник алень и приносит убытки Бизнесу. Накопил дизлайков — депремирование или вообще на поиски работы. Бизнес же заплатил ИТшнику за работу те, несколько десятков рублей за время которое ИТшнек тыкал пользователя носом в его же, пользователя, касяк. Бизнес заплатил одному, потому что кто то другой не выполнил свою работу добросовестно.
Люди, люди все портят.
НО тут аналитики и методологи предлагают новую тему как оптимизировать ИТ отдел и решить проблемы с его чрезмерной загрузкой, ИТшнеги ж ленивые и им нужны SLA/KPI по новым революционным методикам :))))
Опять полотенце текста, но в общем я мысль, похоже донес.
Но потом прилетает типичный запрос на срочное решение проблемы (инцидент) от бухгалтера, хорошо хоть с скриншотом:
Заголовок спойлера
и понимаете, в описании к заявке нет слов, что в учетной системе с р/с все корректно, и возможно касяк в файле обмена. да фиг с ним с файлом обмена, пускай просто напишет сразу что с Р/С все железобетонно в норме!
Я понимаю, что бухгалтер не полезет в XML/JSON файл смотреть структуру и искать проблемную запись, от него этого никто не требует. Если ошибка есть, то её нужно исправлять в учетной системе в модуле выгрузки — это и есть инцидент который требует участия техподержки/суппортеров учетной системы. Для этого они и есть.
Но заявка исполнится в стиле «ой, а я тут и не заметила что р/с неправильно вбит, кнопка видимо заела». А я, как руководитель, скромно помещу в бэклог вопрос с привязкой к заявке, почему модуль выгрузки не проверяет эту корректность сам до выгрузки файла и было бы неплохо реализовать и чекнуть мож там накопилось чего, и почему бухгалтер не делает выгрузку на сайт фонд соцстраха напрямую, а через файл обмена. Мне когда-нибудь замученные разработчики учетной системы ответят что из коропки этого функционала нет, а конфу они менять не будут, потому что она слетит с поддержки.
Я не могу понять, почему в сервисдесках можно оценить работу специалиста, но нельзя оценить заявку от пользователя. Клиент всегда прав? Но клиент/сотрудник алень и приносит убытки Бизнесу. Накопил дизлайков — депремирование или вообще на поиски работы. Бизнес же заплатил ИТшнику за работу те, несколько десятков рублей за время которое ИТшнек тыкал пользователя носом в его же, пользователя, касяк. Бизнес заплатил одному, потому что кто то другой не выполнил свою работу добросовестно.
Люди, люди все портят.
А что бы Вы предложили со всем этим делать?Вы ничего с этим не сделаете, если нет предварительного отсева соискателей через общее тестирование, ежегодного повторного тестирования, а так же плановых недельных курсов по разнообразным тематикам. Не у всех бизнесов на это есть деньги, не у всех есть понимание что это нужно делать. Кто то банально не хочет. Кому то некогда.
НО тут аналитики и методологи предлагают новую тему как оптимизировать ИТ отдел и решить проблемы с его чрезмерной загрузкой, ИТшнеги ж ленивые и им нужны SLA/KPI по новым революционным методикам :))))
Опять полотенце текста, но в общем я мысль, похоже донес.
Отлично структурировано и описано. Отличный пример того, как работает эта методика. Я занимался внедрением Lean дважды и оба раза убедился, что это отличный механизм, который позволяет решить реальные проблемы.
«админ целый день занимается тем, что старается как можно быстрее снять с себя поступающие задачи и перевести их на клиента» — это вроде бы называлось ловля обезьянок(во всяком случае у нас)?
«админ целый день занимается тем, что старается как можно быстрее снять с себя поступающие задачи и перевести их на клиента» — это вроде бы называлось ловля обезьянок(во всяком случае у нас)?
Sign up to leave a comment.
Как метрики бережливого производства можно применить в задачах Service Desk