Сколько должен получать IT-аутсорс специалист за час работы?

Ну как бы да. Условно постоянные то не растут. Ну все до определенного объема. Т.е. сумма покрытия растет, а административно-управляющие издержки - те же.
В этом смысле - влияют. А производственные издержки - конечно от етого мало зависят на одном уровне технологии.

добавлено через 32 минуты

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

 

так это вроде рентабельность, которая, если высокая, то позволяет снизить цены.
а себестоимость она как была при одном обороте, так такая же и осталась при двух, но опять же, до определенного объема.

 

АУП у аутсорсера тоже есть и эти затраты тоже входят в понятие себестоимости

 

это к чему сказано-то было?
себестоимость не зависит от оборота. чем больше оборотов в единицу времени, тем выше рентабельность.
себестоимость - это абсолютный показатель. рентабельность - относительный.

 

AlTk,
Да нет, не совсем так. Полная себестоимость - это грубо все затраты за период поделить на общий объем выпуска. Поскольку не все затраты растут с ростом объема - при росте объема себестоимость единицы снижается. Это в принципе за редким исключением свойственно всем бизнесам.
Т.е. у тех же админов по вызову есть зп производственного персонала - которая например зависит от утилизация. А равно и аренда офиса, амортизация ноутбуков, зарплата секретарши и уборщицы - которые от утилизации не зависят. Так что с ростом утилизации "себестоимость" часа работ будет падать. Поскольку в производственной себестоимости тоже бывают постоянные затраты, то на самом деле с ростом объемов производства будет падать и производственная себестоимость.
Но Caps насколько я понимаю говорил именно про управленческие расходы. Их конечно в себестоимость включать неверно.

 

это не себестоимость. это рентабельность
себестоимость это абсолютный показатель.

 

Брр. Есть себестоимость единицы продукции, себестоимость передела, завода и т.д. Вопрос о калькулируемой аналитике.
Себестоимость готовой продукции (т.е. единицы готовой продукции) падает при росте объемов производства. Это абсолютный показатель. Т.е. если завод выпустит вместо 100 подшипников 1000 подшипников - то себестоимость одного подшипника скорее всего снизится.

 

да, согласен. не уловил в процессе обсуждения перехода от оборотов к объемам.

 

Ну уж нет. Впрочем, видимо вопрос терминологии. Он прекрасно используется и на этапе сопровождения. Собственно говоря, цикл Деминга непрерывен, поэтому отделять внедрение от сопровождения неразумно.

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

Аргументы? Я все подобные расходы должен из прибыли содержать?

 

Я офигел.

 

Есть такое понятие в бухгалтерии - себестоимость. В том числе себестоимость продаж. Во всех стандартах учета общехозяйственные (ибн управленческие) расходы в них не включаются. Управленческие расходы покрываются не из прибыли, а из "суммы покрытия 1". В себестоимость из всех управленческих включаются только общепроизводственные и общецеховые.
Ну это просто считай что особенности учета. Для нашего обсуждения - считаем что входит в себестоимость, для простоты.

Ну так попробуйте тогда сопровождение по ASAP строить. Посмотрим что получится.

Да ладно. Думаю больше чем на половине проектов солюшн менеджер не используется.

 

там была фраза про цикл Деминга. Plan-Do-Check-Act и снова, Plan и Do...
Строго говоря - внедрение, сопровождение и т.д. в контексте ITIL/ITSM выглядят несколько некорректно...

Насколько я помню, ASAP заточен под внедрение, но никак не под поддержку и сопровождение, не?
Я в очередной раз подозреваю, что под сопровождением мы имеем в виду несколько разные вещи. Точно вот это вот:

?
солюшен позиционируется как средство управления решениями, но никак не только как средство внедрения. и с этим самым управлением там все действительно неплохо. Мониторинг есть, управление запросами есть. много чего еще есть.

Х.з. Я пока что не видел ни одного проекта, который был бы сделан без его использования. Внедренных решений я видел чуть меньше 20. Средняя трудоемкость порядка 60-80 человеко-лет. Количество пользователей от 200 до 1500. Территориально распределенные. Как этой махиной управлять-то?

 

Я могу 10-к назвать где не использовался.

Именно так. Это было к тому что внедрение от сопровождения сильно отличается.

Внедрение - не катит ИТСМ никак. А сопровождение нараз.

Ага, именно его родимого и обсуждаем.

 

Насчет ИТСМ не скажу, а в 3-й ITIL они уже вставили. ********.

 

Сопровождение тоже не катит. Ибо суть сопровождения, в отличии от поддержки, есть проектная деятельность. А там про проекты четко - идите вы в pmb или в prince2. Там даже тонкие вопросы метдологий обошли стороной. Думаю, что к 4-й версии исправятся.

Вот с высказнной выше точки зрения, что любая доработка это проект, внедрение от сопровождения отличается вобщем то и не сильно. Вообще, понятие "сопровождение", оно скорее глубоко российское. Я тут недавно имел беседу с совсем непоследними людьми (по крайней мере по эту сторону океана) в одной из наикрупнейших IT корпораций (с названием из двух букв - чтоб окончательно снять вопросы), так вот они мне все как один, утверждали, что понятие "сопровождение" в Европе отсутствует. Т.е. на мои вопросы "а как мы потом будем развивать вот это..." мне говорили, что только в России готовые проекты потом самостоятельно дорабатывают напильником. Во всем остальном EMEA (врут, правда, думаю), такого нет. Есть сданый проект, надо что-то - извольте - новый проект... Для них, вот эта самое российское "сопровождение" было абсолютно в диковинку.

Ну, не совсем так. См. выше. На самом деле, я не вижу ничего плохого в этом - в конце концов, еще раз, "цикл Деминга еще никто не отменял". А всякое производство вобщем то крутится вокруг оного...
Давайте без дураков -внедрение внедрению рознь. Глупо сравнивать внедрение коробочного продукта (кстати тоже не совсем простое дело, как кажется на первый взгляд), с внедрением ERP-системы. Далее, внедрение как тиражирование и внедрение как разработка с нуля, тоже два разных внедрения. Это один момент.
Теперь второй момент. На текущий момент в отрасли сложилась ситуация, когда стандартов разработки ПО стало несколько многовато, не находите? Окромя чисто ведомственных (ASAP, MSF), есть и вполне универсальные (RUP, PRINCE2) и над всем этим возвышается стандарты оценки и совершенствования, такие COBIT, Six Sigma и CMMI (это я максимум процентов 30 упомянул). Уважаемые знатоки, внмание вопрос: "А не дохера ли будет?". Сложно сказать куда оно развернется, но рискну предлположить, что ITIL, позиционирующая себя как библиотека передового опыта, так или иначе охватит процесс разработки/внедрения более полно. И именно в управлении качеством и оценке зрелости этом будет состоять основная идея перехода от третьей версии к четвертой. В качестве правильной методологии разработки останутся лишь те, которые пытаются использовать процессный подход, и соответвенно максимально типизированны/стандартизированны/унифицированны. Рискну предположить что это будет нативный PRINCE2 (хотя и RUP не исключен). Т.е. стандарты, в которых макисмально все разжевано и разложено по полочкам. IT все более и более становится похожим на настоящее производство, что с одной стороны радует - так как отрасль становится по-настоящему зрелой, а с другой, увы, - вспоминается статья про четвертую информационную революцию...

 

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

 

в нашей стране законодательство шаткое - довольно часто меняются правила игры, как по крупному - так и по мелочи. Вдарило в голову налоговой изменить наименования в счетах-фактурах на полное + краткое - что, затевать новый проект? А фактуры то уже сегодня новые надо создавать. Таким образом, сопровождение - некий вариант проектной деятельности по абонентской схеме. Правда, опять же, вчплывает вопрос необходимости компетентной службы зказчика для определния объёмов этой самой абонплаты.

 

Не любая доработка это проект.

Не знаю, может для компании из 2-х букв это и в диковинку, а вот Филип Моррис - совершенно спокойно сопровождал с модификациями - по-крайней мере абаперов заказывал. А SEB - на всю контору имеет z-разработок в числе менее 10 (ну это не считая SL-ных юзер-экзитов конечно). Так что это разные подходы просто.

ASAP к разработке вообще никакого отношения не имеет!!

Внедрение от сопровождения отличается кардинально. На сопровождении нужно управлять инцидентами ну или запросами на обслуживание - кому как больше называть нравится. Инцидент может требовать доработки ПО.
Грубо говоря конечно внедрение - тоже можно считать инцидентом. Только вот внедрение - это инцидент который займет 60-80 человеколет. Этим инцидентом нужно как-то управлять. Так что разница ну очень существенная.

 

поддерживаю

 

Проектная деятельность не может быть по абонсхеме. Это вытекает из определения проектной деятельности.

 

И то не во всех.
ЗЫ: Нах не надо это (внедрение) в ITIL. Надо отделять внедрение от экплуатации. Причем циклу Деминга это ну никак не противоречит.

Брешут хапешники. И там тоже такие же люди. Т.е. где-то может и такой подход, но в целом сопровождение весьма распространенная вещь.

Смотря кому. Да и в общем пусть будет, разве кому мешает. Пользуйся чем нравится.

 

+много
а иначе зачем придумывать ИСО/МЭК 14764-99

 

Ты не прав. Никто не требует соблюдать ее в полном объеме. Опять же, понятия типа "уровень зрелости" никто не запрещал. Я слабо верю, что подобные библиотеки масштабируемы, если только не считать масштабированием, "вот этот процесс внедряем, вот этот нет". Ну зачем в "сраной сетке на 20 компов"(с), demand или блок csi. Просто глупо - ибо не стоят эти риски этих денег. Другое дело, да, ряд моментов, какие риски ключевые для данной сетки, а какие для крупного холдинга можно было и попытаться расписать...

ну ты знаешь наш подход - если более N чел/часов, то вобщем-то отдельный бюджет, иначе - в рамках сопровождения. Не лишено смысла, в общем-то. У меня вон вообще - проектов по пальцам пересчитать, а объем на сопровождение - порядка 40% от общего объема трудозатрат.

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

ну я тут под разработкой имел ввиду полный цикл - т.е. именно внедрение/проектную деятельность.

Хе-хе. Это поддержка.Service Desk в чистом виде.

В общем случае не может. Иначе это не инцидент.

ошибка в заводской прошивке железки может стать причиной инцидента. но изменение прошивки уже не имеет отношения к процессу управления инцидентами.
На эту тему (для внедренческих решений) существует процесс управления релизами.

Аргументы? Не путайте ITIL c ITSM. В блоке SM оно действительно, нах, не надо. В самом ITIL - надо. Вы видимо, более-менее нормально знакомы с v.2 и поверхностно (особенно 1-2 тома) с v.3. Третий он достаточно стройный, и во главу угла поставлено управления жизненным циклом сервиса начианая с хотелки и кончая выводом из эксплуатации.

Да не спорю я особо. Вопрос в стартегии сопровождения. Да и насколько я помню, тот стандарт не описывает методы реализации.
Давай так, модернизация, которая оставит от приложения только название, это сопровождение или нет? С моей точки зрения вообще ничего не изменилось. Был некоторый Chg, который изменил один единственный CI. С вашей точки зрения - был серьезный процесс внедрения. Если честно - нет у меня понимания того момента, когда софт перестает быть софтом и становится сервисом. Есть подозрение что правы мы все - каждый со своей колокольни.

 

наш подход знаю, но мы тут за идеальное решение вроде как трем. Ну и как всегда проблема с пограничными ситуациями - это всё еще поддержка или уже проект? Кто должен иметь право решающего голоса - заказчик или исполнитель? Заказчик знает свои потребности, зато исполнитель -предметную область.

это то понятно, однако что делать, когда необходиомсть в доработках возникает регулярно? Каждый раз мутить проект? Административно долго и, возможно, дорого. Опять же, исполнителю лучше держать одного и того же человека, чтобы он был в курсе проблематики и особенностей бизнеса клиента. Хорошо бы от этого уйти, формализовав всё до предела, дабы максимизировать взаимозаменяемость сотрудников исполнителей, но где такое реализовано ан 100%?

 

Почти угадал. v2 так скорее из опыта работы и жизненного опыта. v3 прошел курс и сдал экзамен на Foundation когда он только вышел как 3 месяца, еще никаких книг не было, только общий тренинг. Ну и опять же как практик больше касаюсь, хотя неглубоко.

Я тебе по жизни говорю, нах не нужно это. Есть методологии эксплуатации. Есть методологии внедрения. И там и там должно быть описано как стыковаться (типа как в MSF+MOF). Но единая нах не нужна. Не интересует эксплуатационщиков как эта хрень зародилась, кто и как ее разрабатывал и т.д. Они должны грамотно принять в эксплуатацию и дальше осуществлять поддержку/сопровождение. И наоборот тоже самое. По херу разработчику сервиса кто и как его эксплуатирует. Как организуется CAB, кто в него входит, как часто собирается. Проект выполнен, внедрен, акты подписаны. Все точка.

И это правильно.

добавлено через 3 минуты

Делается change request и затем исполняется (если конечно не отвергается). Нафига проект?

Держать в данном случае одного исполнителя как раз правильно. И нафик взаимозаменяемость. Как раз если будешь мутить проекты то у тебя будет куча взаимозаменяемого народа, но КПД в районе 10%

 

Что делать с уже упоминавшимся гостом/исо? Где написано, в частонсти, что стратегия сопровождения определяется до проектирования? И еще много чего написано.. Так что насчет того что не должно быть едино - более чем спорно.

 

Как то не верится. Что значит до проектирования, еще когда ФТ пишутся? Что-то сомнительно.

 

Caps,
jek,
не до проектирования, а во время

то есть качественные оценки уже есть, остались количественные

 

AlTk,
Так это уже принятие в эксплуатацию. Тут вполне логично все. Как я уже писал каждая методология в отдельности должна учитывать момент передачи/приема в эксплуатацию. Все остальное не парит.

 

в обычном месяце без праздников исключая февраль - 21, 22 или 23 рабочих дня, это 168, 176 или 184 рабочих часа соответственно