gifts2017

Философия пенетрации

Опубликовал Сергей Алферов (SunShinne) в раздел Управление - Бизнес-процессы

Данная статья предназначена в первую очередь внедренцам и руководителям. Если Вам по роду своей деятельности приходится сталкиваться с тем, что проекты буксуют, сотрудники устраивают саботаж и не квалифицированно выполняют свою работу, то здесь Вы обязательно найдете для себя полезные мысли. Итак, тема обсуждения - контроль, и в данной статье может несколько жестоко, но правдиво раскрыты нюансы, связанные с контрольной функцией. Коллеги, буду также рад услышать Ваши комментарии, о том, какие методы и способы контроля применяете лично Вы.
Большинство так называемых epic fail'ов  проектов в работе (да и в жизни вообще) происходит из-за ненадлежащего контроля. Эта такая настолько банальная истина, но ею многие почему-то пренебрегают. Что такое контроль? Это проверка производимых действий на предмет их правильности, полноты и своевременности с целью выявить имеющиеся отклонения от планов и нормативов и в случае обнаружения таковых принять меры, направленных на устранение отклонений либо корректировку планов и нормативов. Соответственно, самое сложное в контроле это определить планы и нормативы. Если мы говорим о бизнес-системах, то в случае если система достаточно сложная не всегда целесообразно разрабатывать максимально детальный план (нормативы) до старта проекта, иногда рентабельнее будет задать некую минимальную планку качества, а затем ее постепенно повышать. Что касается конкретных способов и подходов контроля в информационных системах, связанных с бизнес-процессами и их учетом, то наиболее эффективными видятся следующие способы:

1) Постоянное, системное совершенствование нормативов. Разумеется, информация об изменениях должна доводится до исполнителей;

2) Выборочные проверки. Случайно, возможно с определенными приоритетами, проверка введенных в систему данных, и процессов вообще, причем проверка не должна формально отрабатывать некий чек-лист с возможными ошибками, необходим всесторонний не предвзятый анализ, для того, что бы можно было обнаружить некие новые виды ошибок;

3) По-возможности программно блокировать определенные виды ошибок, простой пример - это запрет на продажу отрицательного количества. Однако здесь следует соблюсти баланс между снижением скорости системы вследствие ввода новых проверок и их полезности, возможно, достаточно будет заблокировать наиболее критичные с точки зрения оперативности ошибки, а незначительные выявлять позже тестами;

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

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

6) В отдельных случаях не бойтесь принять на вооружение презумпцию виновности - есть подозрение на ошибку - требуйте объяснение. Сотрудникам зарплату не просто так платят, иногда можно их бездоказательно объявить виновными и заставить отстаивать свою правоту. Опять же, это конечно бесчеловечно, аморально и я сам осуждаю такой подход, но  иногда только так можно сдвинуть проект/процесс с "мертвой точки". Где-то прочитал замечательный афоризм: "Я знаю три способа узнать правду. Первый - провокация. А остальные два я забыл.";

7) Процедуру определения виновных следует организовывать так, что бы максимально избежать всех возможных конфликтов интересов. Иначе говоря - следует разделять законодательные органы, судебные и исполнительные. Иногда мне кажется, что на предприятие должно быть лицо с прокурорскими полномочиям :) Смысл таков - важно на выходе требовать конечный результат - ФИО виновного в ситуации. А затем с него, в свою очередь, объяснительную. Часто только столкновение лбами и очные ставки позволяют выяснить реальное положение дел. Мой опыт говорит, что руководители зачастую даже не догадываются о наличии у сотрудников подпольных схем. Начиная от невинной лжи в ежедневных отчетах и заканчивая воровством. Извините еще раз за терминологию - но сотрудников надо "дрючить". В одной крупной российской компании (по этическим соображениям не буду называть в какой, но не в той в которой сейчас работаю) подобный подход называли "пенетрацией". Работало, надо признать.;

8) Мотивация/демотивация. Бывает финансовая и не финансовая. Важно применять оба варианта. Но это отдельная тема на пару книг, скажу только, что писанина объяснительных записок занятие не самое приятное, и только в силу этого работает само по себе. Когда вопрос касается денег сотрудники просто взахлеб начинают рассказывать, что их нужно мотивировать дополнительными премиями, увеличивать зарплаты, как они много работают и все такое. Нафиг. Во-первых - слишком высокие зарплаты вреднее средних, т.к. сотрудники начинают думать не о своей работе, а том как бы сохранить уровень зарплаты любыми средствами, и, поверьте, работа в числе этих самых средств занимает далеко не первое место. Во-вторых - мотивация нужна исключительно для дрессировки персонала. Не для того, что бы платить больше или меньше, а для того, что бы воспитывать правильный подход к работе.

 

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



P.S.:
Анекдот в тему: "Вчера к нам приходил бизнес-консультант, предлагал услуги по совершенствованию системы мотивации. Начал он так: Все знают про такой известный способ  мотивации, когда перед сотрудником вешают морковку и он идет за ней. Я же предлагаю расширить подход, кроме морковки спереди применять еще и морковку сзади..." Тут я понял, что нам не нужен такой консультант.... " :)
 

См. также

Подписаться Добавить вознаграждение

Комментарии

1. John Smith (PiccaHut001) 21.02.13 16:40
Увидел в статье два слоя. Первый - технический, на уровне начинающего программиста: "давай подчёркивать незаполненные обязательные поля красненьким, а если их всё таки не заполнили, то не давать записать документ. И ещё, чтобы не могли списать товар в минус. Ну и тестилок побольше, да.". Ужасно, ужасно, действительно фашизм. Второй слой - непосредственно воображаемая "пенетрация", о которой так мечтает автор: "вот посажу к себе на коленки бухгалтершу до 30 и начну ""дрючить"".". Автор далёк от реальной жизни, он не знает, как и кого можна/надо "взбадривать". К сожалению, руководителям проекта, а тем более внедренцам, по статусу можна ""дрючить"" только своих непосредственных подчинённых: студента Серёжу, консультанта Колю и программиста Романа Ивановича, которому уже 45. Ещё руководители проекта могут писать e-mail с служебками/отписками/объяснительными почему ещё не внедрили, хотя обещали полгода назад, мол, всё это пользователи виноваты. Внедренцы, руководители проекта важны, но не очень, успешность внедрения зависит только от одного: есть заинтересованный в результате топ менеджер, который может выбить адекватные средства и эффективно прогнуть среднее звено. Команды топа передаются цепочкой по иерархии и даже у рядовых сотрудников заблестят глаза и появится энтузиазм, свергаются горы и проект успешно внедряется.
2. Михаил Соколов (mixa4) 21.02.13 17:10
Зачем такую статью писать - представить можно, например, чтобы автору попытаться систематизировать свои мысли, но вот зачем ее кому-то читать - представить не могу: тем, для кого эти вопросы актуальны, имхо статья даст чуть меньше чем ничего.

(1) PiccaHut001, замечу, что автор написал не "списать товар в минус", а любопытнее: "продажу отрицательного количества" :)
wolfsoft; PiccaHut001; Yury1001; +3 Ответить
3. Anatolii Karasev (KapasMordorov) 21.02.13 17:29
Видно продвижение автора по службе в соответствии с принципом Питера.
Сначала технического и методического характера статьи и вот пик: философствование о наболевшем, то бишь о пенетрации, дрессировке, фашизме и семантических тестилках, основанных на наименованиях статей ДДС.
4. Сергей Алферов (SunShinne) 21.02.13 17:39
Кстати, тема с тестилками очень перспективная. Я не знаю точно сколько у нас сейчас их, но за сотню-другую перевалило уже давно. Учет здорово в чувство приводит, и самое главное экономит массу времени и нервов.
5. Сергей Алферов (SunShinne) 21.02.13 17:48
(3) KapasMordorov, спасибо, что не эффект Даннинга-Крюгера :) А методологические статьи последнее время писал для электронной библиотеки журнала Финансовый директор, там соответственно есть условия экслюзивности, на блог и инфостарт времени не было.
6. Anatolii Karasev (KapasMordorov) 21.02.13 18:07
Не, мне тестилки не нравятся.
1. Если их нужно вруную запускать, то эффекта нет. Если пользователь перед продажей ОС забыл амортизацию за предыдущий месяц начислить, то точно также он забудет и про проверочный отчет.
2. Если всё сделать на автомате, то проседает производительность и нужен механизм исключений. На все глупости дурака заборов не построишь, а "пенетрировать" не хочет руководство дурака, т.к. сами такие же.
7. Сергей Алферов (SunShinne) 21.02.13 18:20
У нас тестилки это вообще бизнес-процесс. Сам проверяет, сам долбит пользователей, сам делает отчеты для руководства. Все на автомате. Пополняем периодическими новыми ошибками и злостных нарушителей выявляем. Самое приятное, что снижается уровень личных конфликтов. Это же не я говорю что Вася дурак, а программа сухо и кратко прислал ему перечень ошибок. К кому претензии, разве что к СкайНету :)
А так, да, соглашусь, все глупости не предусмотришь, это 100%. Но, как говорится, 80% эффекта за 20% затрат, это выгодно.
8. Яков Коган (Yashazz) 22.02.13 13:02
Соглашусь с (1) в части роли топ-менеджера. Для внедрения не нужно ничего, кроме мощного административного ресурса. Если он есть, даже криворукое-кособокое решение худо-бедно внедрится и заработает, а если руководящей воли нет, самое шикарное изделие можно спокойно хоронить.
9. Алексей Роза (DoctorRoza) 22.02.13 21:09
Да уж, галиматья написана порядочная! Контроль - это и ежу понятно, что нужен! Самое простое - это отчет сотрудника о своей работе за период. Если он доложил, что сделал, вот от сюда и пляшите! О то бред какой то, контроль, проверке внеплановые. У хорошего директора нет времени на эту ерунду, он апеллирует отчетами своих работников и докладами руководителя проекта. Правильно было сказано коллегой- вы от реальной жизни оторваны!
10. Alex Stasyuk (GreenFox) 23.02.13 01:50
А я считаю что здравые мыслы есть - особенно понравилось на счет высокой зарплаты - и ведь автор прав - у таких людей будут виноваты все - програмисты, консультанты, руководитель проекта, НАТО, НЛО и т.д. а я тут такая вся деловая и умная. Да Вы что я здесь уже 5/10/15 лет работаю и очень ценный работник, я не могу ошибаться.
Особенно нравится: Сделайте как в семерке.
11. Сергей Алферов (SunShinne) 27.02.13 12:55
Мда, перечитал, статья какая-то скомканная вышла. Не вариант значит с телефона писать блоги :) Друзья, не буду биться головой и доказывать, что я практик до мозга костей, и что в статье очень ценные советы есть. Не смог значит донести сам виноват. К сожалению вряд ли найду время более детально написать да и аудитория здесь преимущественно та - которая себя будет ассоциировать с теми, кого пенетрируют, а не с теми кто :) Но, ежели, уважаемый читатель, ты руководитель проекта, или руководитель службы, которой по ходу деятельности приходится иметь с контролем - поверь, если ты простишь мне мой корявый язык и скомканность статьи и прочитаешь медленно, вдумчиво и помедитируешь над материалом - то найдешь там очень ценные и, простите за нескромность, отточенные практикой советы.. удачи всем!
12. Михаил Соколов (mixa4) 27.02.13 14:40
Не скомканная, а просто бессодержательная, вот о чем вы пишите, что нужно планирование и нормативы, что это самое сложное (и о чем дальше ни слова), что нужен контроль - всесторонний, чтобы не тормозил, автоматический, совершенствующийся и т.д. Ну это же, простите, очевидно для человека со средним соображением, перед которым стоят такие задачи, и ему лучше "помедитировать" не над этим материалом, а над своими задачами.
И вообще, статья в итоге сводится к тому что "сотрудников надо дрючить", но это для современного внедренца - первобытный подход, как в ухаживании за бабой - дубиной по голове её и в кусты.
Когда скомканность присуща самой задаче, то скомканное решение может лишь сильнее запутать, приводите мысли в порядок, и я уверен вам будет чего толкового написать коли есть реальный опыт.
13. Константин Куликов (Светлый ум) 01.06.13 10:30
mixa4, не совсем согласен. Человек поделился опытом и аргументированно обосновал тезисы, если директор прочитает статью и сделает вывод что сотрудников надо "дрючить" это будет лишь поверхносное восприятие.
Согласен с автором - проекты надо контролировать, и необязательно провоцировать сотрудников: иногда вполне достаточно задать пару безобидных вопросов (над чем работаешь в данный момент), чтобы застать в расплох лентяя.
Даже сильные и самодостаточные спецы без контроля начинают если не бездельничать, то смотреть по сторонам в поисках дополнительной наживы.
14. anry mc (AnryMc) 01.06.13 10:45
Коллектив и организация – в контексте управления персоналом – синонимы. Но в них кроется и две составляющих данного образования:
«Механическая» - организация – совокупность бизнес процессов, штатных обязанностей, …
«Психологическая» - коллектив – совокупность исполнителей, каждый «со своим скелетом в шкафу…»
Соответственно есть две крайности управления:
Регламент – как правило, наиболее применим на поточном производстве (конвейере), где достаточно, что бы исполнитель точно выполнял свои функции.
Мотивация – как правило, используется в творческих коллективах, зависящих от «идеи» или фирмах "семейного" типа
Ну а в жизни - «Истина где-то рядом»

В соответствии с выбранной моделью управления в принцип «кнута и пряника» вмешивается некоторое «смещение приоритетов» - морковка спереди или сзади.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа