Да, к сожалению, такое на рынке встречается, когда единственной целью заказчика является снижение костов и он недобросовестно обходится с подрядчиками. Как правило, в итоге команда исполнителей меняет работу и все остаются в проигрыше. Чтобы не попасть в такую ситуацию имеет смысл очень тщательно выбирать аутсорсера и осознанно обсуждать условия контракта.
Обосновать дополнительное финансирование через аутсорсинг если и проще, то только в каком-то отдельно взятом случае. Как правило, по нашему опыту, речь идёт об уменьшении затрат, несмотря на то, что происходит на рынке:(
Agile всё-таки больше про разработку, чем про сервис. Но интересно, что это одна из методологий, нацеленная на то, чтобы направить проектно-ориентированных людей в сервисное, нацеленное на запросы заказчика, русло. По успешности есть вопросы. Слышал очень мне понравившийся комментарий "Agile - неограниченная разработка, требующая неограниченного бюджета". А профессиональный сервис предполагает, что исполнитель берет на себя практически все риски неработоспособности поддерживаемого решения.
Я бы сказал, что чем больше управленческой составляющей в обязанностях, тем больше проявляется нацеленность на результат, но это уже другой этап профдеформации
Приветствую! Тут целый комплекс инструментов. И по каждому решению можно отдельную статью написать). Если кратко, то:
Финансы (P&L сервисного направления) трекаем в корпоративной системе.
ЗИП (в том числе и расходники для ремонтов) регулярно выгружаем из 1с в самописный продукт, туда же попадают данные по статистике ремонтов из кол-трекинговой системы (джира) и уже обработанный результат попадает к экспертам в табличном виде.
Загрузку инженеров анализируем на основе данных, получаемых из той же джиры, собственной базы истории пресейловых расчетов и самописного робота с элементами AI, к.т. подсвечивает проблемные области и выдает прогнозы по загрузке.
В случае, если вендор присутствует на нашем рынке, можно закупить его поддержку. Как правило, чем больше у интегратора компетенций, тем больше опций гибкости в вопросе распределения L1..3 между интегратором и вендором.
Если вендор только выходит на наш рынок, то он еще более лоялен, но тут ему интересны не только и не столько наши технические компетенции, наличие лабы и ЗИПа, сколько охват рынка и потенциальный объем поставок.
Если вендор ушел с нашего рынка, то кроме личных контактов на инженерном уровне, есть опция покупки аналогичного оборудования (с сервисом) в нашу лабораторию дружественных интеграторов, расположенных в других странах и открытия кейсов под это оборудование. Но это дорого и, на практике, используется редко.
Спасибо за статью! Тимлидам не позавидуешь. Расстрельная роль.
На мой взгляд, если использовать армейские аналогии, то тимлид-это старшина или прапорщик, а руководитель - офицер. Роли, по мере повышения уровня, меняются от тактической до стратегической. Тактические ошибки видны сразу, а стратегические - в далекой перспективе. Поэтому прежде, чем кто-то поймет, что проблема была вызвана некачественным руководством, по шапке получат именно тимлиды. А вот с успехами дело обстоит несколько иначе. "Руководитель- молодец, а тимлид выполнил все руководящие рекомендации". И, как следствие, демотивация тимлида и потенциальный конфликт с руководством. Так и напрашивается открытый разговор с начальством ;) иногда, проблему можно решить своевременным признанием успехов и выстраиванием роадмапа дальнейшего развития для тимлида (не просто, но возможно)
Здравствуйте, спасибо за статью. При прочтении возникли вопросы:
Не совсем понятно, что делать с прогнозом замыкания на практике. Менять обмотку? Проводить дополнительную диагностику?
Поменяли обмотку (очевидно, ни разу не простая операция) или электронный блок, по которому предсказывается выход из строя. А как дальше анализировать данные по этому трансформатору? Очевидно, что поведенческий паттерн будет отличаться от других объектов, которые живут в своем жизненном цикле техобслуживания и реактивных ремонтов.
Да, к сожалению, такое на рынке встречается, когда единственной целью заказчика является снижение костов и он недобросовестно обходится с подрядчиками. Как правило, в итоге команда исполнителей меняет работу и все остаются в проигрыше. Чтобы не попасть в такую ситуацию имеет смысл очень тщательно выбирать аутсорсера и осознанно обсуждать условия контракта.
Обосновать дополнительное финансирование через аутсорсинг если и проще, то только в каком-то отдельно взятом случае. Как правило, по нашему опыту, речь идёт об уменьшении затрат, несмотря на то, что происходит на рынке:(
а чем, в итоге, все закончилось-то?
Agile всё-таки больше про разработку, чем про сервис. Но интересно, что это одна из методологий, нацеленная на то, чтобы направить проектно-ориентированных людей в сервисное, нацеленное на запросы заказчика, русло. По успешности есть вопросы. Слышал очень мне понравившийся комментарий "Agile - неограниченная разработка, требующая неограниченного бюджета".
А профессиональный сервис предполагает, что исполнитель берет на себя практически все риски неработоспособности поддерживаемого решения.
Я бы сказал, что чем больше управленческой составляющей в обязанностях, тем больше проявляется нацеленность на результат, но это уже другой этап профдеформации
Спасибо за комментарий. Насчет короткой дофаминовой петли ОС тонко. Действительно, похоже.
Спасибо за комментарий. Насчет короткой дофаминовой петли ОС тонко. Действительно, похоже.
Статья хорошая, тема острая, посыл правильный, но очень затянуто.
И грамматические ошибки отвлекают.
Дошел до второй ошибки и поймал себя на мысли, что читаю через силу.
Приветствую!
Тут целый комплекс инструментов. И по каждому решению можно отдельную статью написать). Если кратко, то:
Финансы (P&L сервисного направления) трекаем в корпоративной системе.
ЗИП (в том числе и расходники для ремонтов) регулярно выгружаем из 1с в самописный продукт, туда же попадают данные по статистике ремонтов из кол-трекинговой системы (джира) и уже обработанный результат попадает к экспертам в табличном виде.
Загрузку инженеров анализируем на основе данных, получаемых из той же джиры, собственной базы истории пресейловых расчетов и самописного робота с элементами AI, к.т. подсвечивает проблемные области и выдает прогнозы по загрузке.
про идейность и сервисность я постараюсь в следующей статье написать.
К хорошему, но неидейному профессионалу, нужен просто особый подход.
Есть несколько вариантов.
В случае, если вендор присутствует на нашем рынке, можно закупить его поддержку. Как правило, чем больше у интегратора компетенций, тем больше опций гибкости в вопросе распределения L1..3 между интегратором и вендором.
Если вендор только выходит на наш рынок, то он еще более лоялен, но тут ему интересны не только и не столько наши технические компетенции, наличие лабы и ЗИПа, сколько охват рынка и потенциальный объем поставок.
Если вендор ушел с нашего рынка, то кроме личных контактов на инженерном уровне, есть опция покупки аналогичного оборудования (с сервисом) в нашу лабораторию дружественных интеграторов, расположенных в других странах и открытия кейсов под это оборудование. Но это дорого и, на практике, используется редко.
Спасибо за статью! Тимлидам не позавидуешь. Расстрельная роль.
На мой взгляд, если использовать армейские аналогии, то тимлид-это старшина или прапорщик, а руководитель - офицер. Роли, по мере повышения уровня, меняются от тактической до стратегической. Тактические ошибки видны сразу, а стратегические - в далекой перспективе. Поэтому прежде, чем кто-то поймет, что проблема была вызвана некачественным руководством, по шапке получат именно тимлиды. А вот с успехами дело обстоит несколько иначе. "Руководитель- молодец, а тимлид выполнил все руководящие рекомендации". И, как следствие, демотивация тимлида и потенциальный конфликт с руководством. Так и напрашивается открытый разговор с начальством ;) иногда, проблему можно решить своевременным признанием успехов и выстраиванием роадмапа дальнейшего развития для тимлида (не просто, но возможно)
Здравствуйте, спасибо за статью. При прочтении возникли вопросы:
Не совсем понятно, что делать с прогнозом замыкания на практике. Менять обмотку? Проводить дополнительную диагностику?
Поменяли обмотку (очевидно, ни разу не простая операция) или электронный блок, по которому предсказывается выход из строя. А как дальше анализировать данные по этому трансформатору? Очевидно, что поведенческий паттерн будет отличаться от других объектов, которые живут в своем жизненном цикле техобслуживания и реактивных ремонтов.