Усі матеріали

Жили в лісі мишки, і всі їх кривдили.

Вирішили вони попросити поради в мудрого пугача. Прийшли й кажуть:

— Мудрий пугачу, допоможи порадою. Усі нас кривдять, ми маленькі.

Що нам робити?

Пугач подумав і каже:

— Відростіть колючки. Тоді станете як їжачки: вони хоч і маленькі, але мають колючки, і їх ніхто не кривдить.

Мишки зраділи й побігли додому. Та дорогою одна мишка сказала:

— А як же нам відростити колючки?

І всі побігли назад, щоб поставити це запитання мудрому пугачеві.

Прибігли й запитали:

— Мудрий пугачу, а як же нам відростити колючки?

І відповів їм пугач:

— Друзі, не завантажуйте мене дурницями. Я стратегією займаюся.

Анекдот

Усе описане нижче — поєднання того, що я бачив у різних компаніях за час своєї кар'єри. Причому не лише в тих, де працював, а й у тих, із якими взаємодіяв, зокрема в консалтингу. Так, це також, але не лише, мої граблі.

***

Не варто чекати дива.

Чарівної пігулки не існує.

Жоден бізнес-аналітик — зовнішній чи внутрішній — не прийде й за тиждень або місяць не знайде простого та швидкого рішення, яке втричі скоротить витрати й удвічі збільшить прибуток.

Цей допис не про те, що від аналітиків немає користі, що аналізом та оптимізацією бізнес-процесів не потрібно займатися. Він про інше: радше про те, що один у полі не воїн, що реінжиніринг бізнес-процесів — це спільна робота всіх: першої особи, топменеджерів — далі я часто називатиму їх функціональними керівниками, маючи на увазі очільників підрозділів, — і, звісно, аналітика.

Цей допис на конкретних прикладах, зокрема моєму власному, розповість про деякі помилки організації внутрішнього консалтингу. Сподіваюся, це буде корисно тим, хто замість бігу по граблях обирає аналіз чужих помилок.

Господи, дай мені сили змінити те, що я можу змінити, дай мені мужності прийняти те, чого я не в змозі змінити, і мудрості відрізнити одне від іншого

Імовірно, Райнгольд Нібур

Чи траплялося вам ображатися на свого роботодавця?

«Та я стільки зробив, ніхто цього не цінує. Нікому це не потрібно. Усе!!! Тримайте мене семеро, я йду».

Або навпаки: ваш підлеглий із власної ініціативи виконав велику роботу, гордо демонструє результат, а ви розумієте, що:

— контролювати потрібно було частіше, давати більше зворотного зв'язку;

— це загалом і не потрібно, є важливіші й потрібніші речі, шансів запустити це — нуль.

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

Почну з двох історій, а потім зведу їх докупи й доповню абстрактними прикладами. 

- Фу! До чего же дичь пошла бестолковая — я полдня за ней бегал, чтобы сфотографировать!
- Это ещё мало, теперь ты ещё за ним полдня бегать будешь.
- Это почему же?
- А чтоб фотографию отдать.

Канікули в Простоквашині

Усе наведене нижче я писав про внутрішню розробку й підтримку.

Коли завдань багато, а ресурсів ІТ на всіх не вистачає.

Я кілька разів сам наступав на ці граблі. Чув багато історій від колег.

Про схожі проблеми — матеріали «Нікому не потрібний подвиг» і «Супераналітик-оптимізатор».

Тепер суть:

За розробку беруться лише тоді, коли є замовник із чітко визначеною потребою.

Будь-який рядок коду пишуть лише тоді, коли замовник готовий витрачати час і сили на:

• постановку завдання: розмову з аналітиками для складання ТЗ;
• упровадження: роботу з опором, підвищене навантаження під час запровадження.

Лише коли виконано ці умови, можна витрачати час програмістів на розробку, а аналітиків — на складання ТЗ.

Інакше ви дуже ризикуєте уподібнитися Шарикові й бігати за дичиною користувачами і під час складання ТЗ, і, що найнеприємніше, під час упровадження.

Нижче — реальні випадки з граблями, і не лише моїми. Усі імена змінено, всі збіги випадкові.

Під час організації складської логістики трапився цікавий випадок.

Сегмент B2B. Відділ продажів. У ньому майже два десятки менеджерів. У кожного — десятки клієнтів.

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

Компанія мала план продажів у грошовому вимірі, щоб менеджери тягнулися до мети. А от перевести цей план у конкретні товарні позиції вже не було можливості. Затверджених і формалізованих специфікацій продукції як таких не існувало. Відповідно, про плани виробництва й закупівель на його основі не йшлося.

Був оперативний план виробництва на підставі вже отриманих замовлень із горизонтом щонайбільше два тижні. Але на його основі, навіть за наявності специфікацій, керувати залишками сировини неможливо: строк постачання багатьох позицій — місяці.

А сировину ж потрібно закуповувати на підставі чогось?

Компанія нічого нового тут не винайшла: не можна розрахувати — підемо експертним шляхом. Як уже сказано, кожен менеджер відділу продажів формував план закупівель сировини сам для себе.

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

У KPI такого менеджера були продажі, дебіторська заборгованість... Усе як у всіх. От тільки жодної мотивації мінімізувати залишки.

Періодично генеральний директор, звісно, смикав усіх через великий склад. Після цього запаси на складі трохи зменшувалися. На певний час.

Але система не змінювалася. Запаси залишалися великими й далі зростали.

У сировині на складі була заморожена значна сума.

«Бачиш зірку — звільни її.

Підготуйся, наскільки зможеш, і звільни. Якомога швидше.

Від зірки більше проблем, ніж користі.

Це зараз ти думаєш, що це цінний кадр і незамінний працівник.

Що він тягне на собі величезний пласт роботи й замінити його ніким не вдасться.

Що це знахідка.

Але це не так: насправді це проблема. Лише відкладена».

Приблизно такими словами навчав мене один із моїх керівників. Я намагався його зрозуміти, але прийняти це було складно: на той момент я ще жодного разу не стикався із зірковими працівниками та зірковим шантажем.

Чи траплялося вам отримувати якийсь нудний, рутинний, складний і тривалий проєкт?

Я говорю про внутрішні проєкти сервісної розробки.

Саме проєкт і саме тривалий.

Доручають, а потім про нього просто забувають.

Точніше, керівництво пам'ятає, що ви щось там робите, навіть визнає потребу в цьому. Але проєктом не цікавиться. Його результати керівництву не надто потрібні й цікаві.

І все...

Стати помітним, у розумінні авторів Стратоплану (старе джерело наразі недоступне), завдяки такій роботі не вдається.

Результат начебто є, але він нікому не потрібний.

Демотивує страшенно. 

Я чув про людей, які йшли з компанії, попрацювавши певний час над таким проєктом.

Зрештою проєкт найчастіше закривали. Бо ні в кого не було бажання щось далі робити в цьому напрямі.