За статью спасибо — для тех, кому приходиться работать с ГОСТами Вашу статью можно использовать в качестве чек-листа.
Но вот с Вашим утверждением «легко и просто» согласиться не могу.
По моему опыту все действительно легко и просто на внутреннем проекте, когда одни и те же специалисты одна команда и создает документ и впоследствии работает по нему же. В этом случае качество проработки документа именно такое, которое необходимо для дальнейшей работы над системой.
Но как только ТЗ по ГОСТу используется в отношениях Заказчик — Исполнитель на внешних проектах, то значительная часть документа превращается в «воду».
У госпредприятия (а ведь именно они живут по ГОСТам) нет денег ни на предпроектное обследование, ни на аналитика. А в закупку нужно предоставить именно ТЗ и именно по ГОСТу. И часто документ пишется бизнесом напополам со специалистом техподдержки. И они 15 страниц ГОСТа трактуют как бог на душу положит.
И то, что некоторые разделы ТЗ можно использовать в качестве защиты исполнителя я сомневаюсь. Вы действительно полагаете, что заказчик в протоколе испытаний так и напишет что система не работает потому что не хватает персонала?
По моему мнению ГОСТы действительно устарели, т.к. выражаясь Вашими же словами написаны общими словами «за все хорошее, против всего плохого». Шаблонов внутри себя не содержат, требуют составления таблиц «чтобы не запутаться». Без опыта, при чем без правильного опыта, их крайне сложно применять.
Согласна с HawkeyePierce89, что в первую очередь вам нужно посмотреть на внутренние процессы, и начать с планирования и контроля выполнения.
И в вашей ситуации, мне кажется, гораздо более полезнее было бы обладать информацией почему люди устраиваются к вам на работу, если «компания не может конкурировать за кадры с крупными по большому числу аспектов...». А так же информация почему и куда (на какие условия) они от вас уходят.
к премиальной части вознаграждения относятся все суммы сверх оклада, указанного в трудовом договоре: месячные, квартальные, годовые, проектные премии и т.д. Я писала без привязки к какому-либо конкретному виду премии. И сравнивала не с вариантом, когда премией «добивается» доход сотрудника до среднерыночного, а когда премия начисляется по результатам KPI, какими бы не были критерии этого KPI. Т.е. ни в случае депремирования, ни в случае премирования по KPI у сотрудника нет гарантии, что он эту премию получит на 100%. Но в моем понимании депремирование а) проще рассчитывать б) понятнее для сотрудника, чем чем сложнорассчетные формулы по KPI.
В случаях, когда премией «добивается» доход до среднерыночного, решаются несколько другие проблемы. И там вообще не стоит вопрос какой-либо формализации процесса начисления премии, ни по KPI, ни по таблице штрафов.
Все на усмотрение начальства без обязательства объяснять почему начислена или не начислена премия.
Так вот, топикстартер предлагает штрафовать сотрудников не из годовых, квартальных и проектных бонусов
А вы из какой строчки моего текста сделали такой вывод? Нет, это не верное утверждение, речь идет именно о премиях. Предваряя вопросы: сотрудник устраивается на оклад, при устройстве ему рассказывают о возможности премии, но не обещают ее железно.
А где вы увидели в моем комментарии несогласие с тем, что руководитель отвечает за свое подразделение? Да, отвечает и в моем предложении так же и собственными деньгами за ошибки подчиненных. Это кстати, не плохой стимул для начальника: всякую дрянь в список со штрафами не писать, помня, что это и на нем отразится, и процессы выстраивать грамотно.
И личные задачи у менеджера так же есть, немного общего порядка, не операционные. Как пример в контексте задачи — принятие на техподдержку новой системы, изменение графика техподдержки с 5 х 8 на 5 х 12 или 7 х 24, переход на работу по SLA и т.д. Это чисто менеджерские задачи и неплохо менеджеру нести ответственность за них.
Вы в своих предположений не далеки от истины. Задачу менеджера я вижу именно в том, что бы настроить процессы таким образом, что бы они максимально выполнялись без участия руководства. Я против ручного управления и предпочитаю работать с сильными специалистами, которые могут для своих рутинных работ и приоритеты верно настроить, и продумать последствия своих действий. А задача менеджера, например: балансировать нагрузку внутри коллектива, отмахиваться от некорректных запросов пользователей или превращать их в корректные, решать административные вопросы с другими подразделениями, анализировать причины тех же косяков.
Спасибо за ваш комментарий, очень полезный для меня.
Что касаемо «придется выделять часть времени на поиск косяков подчиненных». В общем случае да, так будет. Но какая-бы система расчета премии не применялась, на депремировании или на KPI, — это все равно будет занимать менеджерское время. И, по моим прикидками сопоставимое. А если владелец/высшее руководство компании принимает решение о разработке системы мотивации, у менеджера среднего звена нет возможности для своего подразделения оставить чисто окладную систему.
«Грубые архитектурные ошибки» и «Косяки с бекапированием и потерей данных» вносятся отдельной строкой. И минусуются отдельно.
Изначально я исхожу из ситуации, что и менеджмент и сотрудники как минимум не плохие специалисты. А это значит, что менеджмент на бекап выделил время, а сотрудник вполне может самостоятельно верно расставить приоритеты между бекапированием и рутиной.
Поэтому задача менеджера состоит частично и в том, что бы выстроить процесс таким образом, при котором ошибки рядовых сотрудников не влияли на основной процесс
полностью с вами согласна. Что бы у менеджера была для этого мотивация, эти же критерии для депремирования можно зашить и ему. См. мой комментарий выше.
Проблема в депремировании в том, что это тупо демотивирует сотрудников. Даже если наказывают другого, он примеряет это на себя, практически всегда. «А завтра это могу быть я».
Все-таки мне кажется, что проблема не в депремировании как таковом, а в качестве и субъективности критериев. Все-таки я думаю, что при депремировании есть шанс уменьшить субъективность критериев, но убрать полностью все-равно не получится.
Спасибо за вопрос. Если брать по отделу техподдержки, то за некоторые ошибки подчиненных: за ошибки, вызвавшие незапланированный останов продуктивных систем или приравненных к ним; за отклонение от SLA и регламентов; косяки с бекапами, потерю данных.
Что касаемо непосредственно управленческой работы — кроме срыва сроков при выполнении личных задач ни чего предложить пока не могу. Хотя и считаю этот параметр субъективным.
Если премии мотивируют делать, то штрафы мотивируют не делать.
Очень хотелось бы что да, мотивировали бы не делать. Ошибки.
То есть, делать минимум, лишь бы не попасть под штраф за невыполнение минимума.
если стандартная схема при KPI — 80%, например, закрытых инцидентов — 80% процентов премии, 90% закрытых — 90% премии, 100% закрытых — 100% премии.
При депремировании — 20% не закрытых задач — минус 20% премии, 10% незакрытых — минус 10% премии, 0 не закрытых — 100% премии в плюс. С точки зрения денег для сотрудника — все абсолютно то же самое. Или вам обязательно нужна красивая маркетинговая упаковка в виде более «позитивного» названия подхода?
а) в моем предложении система действительно карательная, это не скрывается и даже подчеркивается хотя бы названием. По-моему это честно и справедливо. В отличие от системы на KPI. Я несколько не понимаю ваше недовольство этим фактом. А вы что предлагаете делать со специалистом, который не сделал бекап перед накаткой изменений? по головке гладить?
б) если у вас есть конкретные советы, какой подход применить в указанных бизнес-процессах (н-р, техподдержка 2-й линии)- сделайте милость,
поучите неразумную. Или вам для полноты картины по бизнес-процессам не хватает именно моего возраста и должности?
Многое зависит от контекста (например, соотношение средних зарплат подразделения со средними зарплатами по рынку), но премиальная часть, на мой взгляд, должна быть не более 50%.
То, что KPI изначально про процессы — это я знаю. Но ни мое знание, ни, увы, ваше, не не влияет на распространенность применения KPI для оценки сотрудников в отрасли в целом.
Какая-то совсем не красивая и не справедливая ситуация оказывается в итоге. Ответственные люди должны работать за положенную законом компенсацию в 2 оклада, а раздолбая увольняют сразу. Если мы имеем в виду честную компанию, то по закону раздолбай как раз и получит компенсацию в отличие от ответственного сотрудника.
На мой взгляд, вот этот кейс про 3 месяца — это про то, как не взять грех лично на свою душу, если политика компании НЕ выплачивать компенсации. Делать все по букве закона (2 недели + 2 оклада по соглашении сторон) как-то повыгоднее будет для работника. В любом случае спасибо — очень надеюсь, что в моей практике это не пригодится, но ситуации бывают разные и не все зависит от меня.
И про «три желтые карточки» — очень правильно! Спасибо!
А что делают эти почти уволившиеся люди 3 месяца? И как они это делают? В смысле укладываются ли в поставленные сроки, выполняют ли неприятно-рутинную работу или только то, что лично для них имеет какую-либо выгоду (например, в плане опыта и навыков)? Не тратят ли основную часть рабочего времени на решение личных вопросов? Как это отражается на коллективе в части морального климата? Думаю, что в вашей практике есть примеры, как и лояльного и ответственного отношения увольняемого сотрудника к компании, так примеры совершенно обратного характера. А общая тенденция какова?
И еще вопрос к автору — в итоге после истечения трех месяцев для поиска работы как увольнялся сотрудник, по собственному или по соглашению с выплатой компенсации?
Я пока сторонница более быстрого расставания и поддерживаю комментарий iehrlich выше ( не могу голосовать).
Системы EDI являются частным случаем электронного документооборота. Они ориентированы на обмен данными с торговыми партнерами или подразделениями торговой сети. Если в общем случае через документооборот проводят любые виды юридически значимых документов, то здесь реализован оперативный обмен коммерческой информацией между организациями, в том числе, юридически значимыми документами, необходимыми для торговых операций.
Да, в России локомотивом EDI является именно торговля. Но в корне не верно указывать EDI прерогативой только этой отрасли. По моим данным в России есть предприятия вне ретейла, использующие EDI, например, стандарт EDIFACT в автомобилестроении.
Есть немного.
В моей идеальной картине мира as is должны получаться из to be сразу после внедрения с отражением всех расхождений, которые образовались в процессе реализации. + должна постоянно поддерживаться актуальность этих схем. Я работаю на стороне клиента и мне, в отличии от внешних консультантов, важно иметь актуальную информацию по процессам: что бы быстро находить нужную инфу, что бы знания не лежали в чьей-то конкретной голове, а были доступны всей команде, для того, что бы разговаривать с пользователями на одном языке и т.д.
Но в жизни, конечно, все не так. Безусловно, крайне не хочется тратить время на as is до внедрения новых оптимальных процессов, но в некоторых случаях, на мой взгляд, это оправдано. Например, в следующих:
а) пользователи крайне неохотно делятся инфой о своих процессах (возможно из-за страха потерять свое насиженное место, уникальность-незаменимость или просто от природного косноязычия, не суть). В таких случаях мне важно отрисовать схемы и получить от пользователей подпись под ними. Что бы потом не было обвинений, что мы что-то не так поняли, упустили, не учли.
б) для иллюстрации каких-либо наших предложений по оптимизации, требующих волевого решения сверху: положительное решение более вероятно, если руководитель сравнивает as is и to be, чем когда просто лицезреет to be.
в) очень часто делаю выборочно схемы просто для себя — они могут понадобиться мне/коллегам позже в случае, если их трансформация под to be отложилась или отменилась.
У внешних консультантов таких необходимостей как правило не возникает, они пришли и ушли, а мне дальше с этим работать. Так что для меня as is — эта работа терапевта или даже этакого врача общей практики.
И да, запутанные процессы иногда распутываются на интуиции и мелких зацепках.
Но вот с Вашим утверждением «легко и просто» согласиться не могу.
По моему опыту все действительно легко и просто на внутреннем проекте, когда одни и те же специалисты одна команда и создает документ и впоследствии работает по нему же. В этом случае качество проработки документа именно такое, которое необходимо для дальнейшей работы над системой.
Но как только ТЗ по ГОСТу используется в отношениях Заказчик — Исполнитель на внешних проектах, то значительная часть документа превращается в «воду».
У госпредприятия (а ведь именно они живут по ГОСТам) нет денег ни на предпроектное обследование, ни на аналитика. А в закупку нужно предоставить именно ТЗ и именно по ГОСТу. И часто документ пишется бизнесом напополам со специалистом техподдержки. И они 15 страниц ГОСТа трактуют как бог на душу положит.
И то, что некоторые разделы ТЗ можно использовать в качестве защиты исполнителя я сомневаюсь. Вы действительно полагаете, что заказчик в протоколе испытаний так и напишет что система не работает потому что не хватает персонала?
По моему мнению ГОСТы действительно устарели, т.к. выражаясь Вашими же словами написаны общими словами «за все хорошее, против всего плохого». Шаблонов внутри себя не содержат, требуют составления таблиц «чтобы не запутаться». Без опыта, при чем без правильного опыта, их крайне сложно применять.
И в вашей ситуации, мне кажется, гораздо более полезнее было бы обладать информацией почему люди устраиваются к вам на работу, если «компания не может конкурировать за кадры с крупными по большому числу аспектов...». А так же информация почему и куда (на какие условия) они от вас уходят.
В случаях, когда премией «добивается» доход до среднерыночного, решаются несколько другие проблемы. И там вообще не стоит вопрос какой-либо формализации процесса начисления премии, ни по KPI, ни по таблице штрафов.
Все на усмотрение начальства без обязательства объяснять почему начислена или не начислена премия.
А вы из какой строчки моего текста сделали такой вывод? Нет, это не верное утверждение, речь идет именно о премиях. Предваряя вопросы: сотрудник устраивается на оклад, при устройстве ему рассказывают о возможности премии, но не обещают ее железно.
И личные задачи у менеджера так же есть, немного общего порядка, не операционные. Как пример в контексте задачи — принятие на техподдержку новой системы, изменение графика техподдержки с 5 х 8 на 5 х 12 или 7 х 24, переход на работу по SLA и т.д. Это чисто менеджерские задачи и неплохо менеджеру нести ответственность за них.
Что касаемо «придется выделять часть времени на поиск косяков подчиненных». В общем случае да, так будет. Но какая-бы система расчета премии не применялась, на депремировании или на KPI, — это все равно будет занимать менеджерское время. И, по моим прикидками сопоставимое. А если владелец/высшее руководство компании принимает решение о разработке системы мотивации, у менеджера среднего звена нет возможности для своего подразделения оставить чисто окладную систему.
Изначально я исхожу из ситуации, что и менеджмент и сотрудники как минимум не плохие специалисты. А это значит, что менеджмент на бекап выделил время, а сотрудник вполне может самостоятельно верно расставить приоритеты между бекапированием и рутиной.
полностью с вами согласна. Что бы у менеджера была для этого мотивация, эти же критерии для депремирования можно зашить и ему. См. мой комментарий выше.
Все-таки мне кажется, что проблема не в депремировании как таковом, а в качестве и субъективности критериев. Все-таки я думаю, что при депремировании есть шанс уменьшить субъективность критериев, но убрать полностью все-равно не получится.
Что касаемо непосредственно управленческой работы — кроме срыва сроков при выполнении личных задач ни чего предложить пока не могу. Хотя и считаю этот параметр субъективным.
Очень хотелось бы что да, мотивировали бы не делать. Ошибки.
если стандартная схема при KPI — 80%, например, закрытых инцидентов — 80% процентов премии, 90% закрытых — 90% премии, 100% закрытых — 100% премии.
При депремировании — 20% не закрытых задач — минус 20% премии, 10% незакрытых — минус 10% премии, 0 не закрытых — 100% премии в плюс. С точки зрения денег для сотрудника — все абсолютно то же самое. Или вам обязательно нужна красивая маркетинговая упаковка в виде более «позитивного» названия подхода?
б) если у вас есть конкретные советы, какой подход применить в указанных бизнес-процессах (н-р, техподдержка 2-й линии)- сделайте милость,
поучите неразумную. Или вам для полноты картины по бизнес-процессам не хватает именно моего возраста и должности?
На мой взгляд, вот этот кейс про 3 месяца — это про то, как не взять грех лично на свою душу, если политика компании НЕ выплачивать компенсации. Делать все по букве закона (2 недели + 2 оклада по соглашении сторон) как-то повыгоднее будет для работника. В любом случае спасибо — очень надеюсь, что в моей практике это не пригодится, но ситуации бывают разные и не все зависит от меня.
И про «три желтые карточки» — очень правильно! Спасибо!
И еще вопрос к автору — в итоге после истечения трех месяцев для поиска работы как увольнялся сотрудник, по собственному или по соглашению с выплатой компенсации?
Я пока сторонница более быстрого расставания и поддерживаю комментарий iehrlich выше ( не могу голосовать).
Да, в России локомотивом EDI является именно торговля. Но в корне не верно указывать EDI прерогативой только этой отрасли. По моим данным в России есть предприятия вне ретейла, использующие EDI, например, стандарт EDIFACT в автомобилестроении.
В моей идеальной картине мира as is должны получаться из to be сразу после внедрения с отражением всех расхождений, которые образовались в процессе реализации. + должна постоянно поддерживаться актуальность этих схем. Я работаю на стороне клиента и мне, в отличии от внешних консультантов, важно иметь актуальную информацию по процессам: что бы быстро находить нужную инфу, что бы знания не лежали в чьей-то конкретной голове, а были доступны всей команде, для того, что бы разговаривать с пользователями на одном языке и т.д.
Но в жизни, конечно, все не так. Безусловно, крайне не хочется тратить время на as is до внедрения новых оптимальных процессов, но в некоторых случаях, на мой взгляд, это оправдано. Например, в следующих:
а) пользователи крайне неохотно делятся инфой о своих процессах (возможно из-за страха потерять свое насиженное место, уникальность-незаменимость или просто от природного косноязычия, не суть). В таких случаях мне важно отрисовать схемы и получить от пользователей подпись под ними. Что бы потом не было обвинений, что мы что-то не так поняли, упустили, не учли.
б) для иллюстрации каких-либо наших предложений по оптимизации, требующих волевого решения сверху: положительное решение более вероятно, если руководитель сравнивает as is и to be, чем когда просто лицезреет to be.
в) очень часто делаю выборочно схемы просто для себя — они могут понадобиться мне/коллегам позже в случае, если их трансформация под to be отложилась или отменилась.
У внешних консультантов таких необходимостей как правило не возникает, они пришли и ушли, а мне дальше с этим работать. Так что для меня as is — эта работа терапевта или даже этакого врача общей практики.
И да, запутанные процессы иногда распутываются на интуиции и мелких зацепках.