Принято думати, що помилок треба уникати, пропоную подивитись на це питання трохи ширше.
По-перше, при певній частоті якихось дій помилки, фактично, невідворотні. І має значення: що ми робимо, щоб їх уникнути (і чи робимо взагалі), як ми на них реагуємо, які висновки робимо.
Стереотипний погляд: помилок треба уникати, будь що, помилки треба виправляти, аналіз помилок потрібен для того, щоб помилки не повторювались.
Це досить "прямий" підхід, ми його, по суті, можемо назвати оптимізацією.
Тобто:
- ми знаємо, що треба робити, в цілому,
- ми виправляємо помилки (тобто корегуємо хибний хід процесу),
- наш аналіз націлений на те, щоб змінити сам процес чи інші фактори так, щоб в майбутньому або таких помилок було менше, або ми їх виправляли ефективніше, а частіше — і те, і інше.
Що ми можемо сказати про ситуацію, коли перший пункт не виконується, тобто ми не знаємо, як досягти мети "правильно" (ефективно, результативно) чи взагалі її досягти?
Такі питання, наприклад, стоять перед винахідниками, іноваторами, взагалі перед тими, хто намагається зробити щось нове, що до цього ще ніхто чи мало хто пробував.
І тоді ми можемо сказати, що помилки, фактично, робляться свідомо (наприклад з експериментальних міркувань), тобто мова про уникнення помилок не йде.
Більше, часто і мова про виправлення помилок в такому разі не йде, бо гіпотеза чи концепція просто відкидаються і все, більше нею мало опікуються.
Аналіз, при цьому, направлений не на виправлення чи на те, щоб більше не повторювати, скільки на вивчення ефектів, що супроводжували помилку, спричинили її, були частиною процесу (часто заздалегідь не врахованою). Тобто фактично помилки, в даному разі, — це свідоме набуття певного досвіду, знань та умінь.
Деякі гуру іновацій пропонують такий підхід: максимально швидко створювати т.зв. MVP (minimal viable product), перш за все з метою перевірки, тобто такий собі "перевірочний" продукт (з цим пов'язаний ще один усталений термін — PoC, proof of concept), швидко перевірити гіпотезу-концепцію і рухатись далі — відкинути, переробити чи розвивати, в залежності від результатів перевірки.
Тобто управління помилками, насправді, дуже і дуже відрізняється в залежності від того, в якому середовищі і за яких умов виникають помилки.
Хочу звернути увагу на момент, чому великим корпораціям важко бути ініціативними: там в управлінні помилками превалює традиційний підхід. І дуже важко обгрунтувати радикально інший, експериментальний.
Відомий приклад, свого часу Марісса Майєр прийшла в Yahoo з Гуглу, фактично, рятувати компанію, що втрачала лідерство і перетворилась на донора спеціалістів для більш успішних конкурентів. На новому місці вона, крім іншого, фактично робила рівно те саме, що робила і в Гуглі: скупала пачками нові стартапи, в надії, що якийсь з них "вистрелить" і витягне компанію в цілому чи хоча б покращить її становище, додасть "нової крові".
Але такий підхід потребує і іншого підходу до помилок, які робляться, фактично, свідомо. Що було важко витримати акціонерам Яху: після кількох коштовних і невдалих покупок Маріссу Майєр звільнили.
Я не певен, що її підхід був правильним, просто приводжу це як приклад різного підходу до управління помилками.
Ще один важливий аспект — реагування на помилки.
Парадоксально, але в реагуванні на помилки консервативні компанії часто-густо роблять традиційну помилку: вони припускають, що помилок не повинно бути взагалі. Їх процеси, буває, просто навіть не враховують теоретичну вірогідність тієї чи іншої помилки. Якщо менеджер скаже, що, в разі такої помилки ми будемо реагувати ось так, — то цілком вірогідно йому накажуть просто не робити таких помилок. І все.
Результатом цього є те, з чим стикався, я певен, кожен з нас, — коли клієнт не може "достукатись" до потрібного працівника, бо у них нема сталого алгоритму реагування на певну помилку (системи чи навіть клієнта — не принципово). І працівники "футболяють" звернення один одному, "піднімають" питання на вищий рівень, аж до такого рівня, де менеджер (буває, що це доходить до топ-менеджерів) може без будь-яких процедур і регламентів просто взяти на себе відповідальність за рішення.
Приклад без імен: одна угода на кілька мільйонів мало не зірвалась через принципове бажання клієнта отримати, як він вважав, справедливу знижку на 50 гривень. Справа була, зрозуміло, не в грошах, а в принципі. І взяти гроші від працівників клієнт відмовлявся, він хотів офіційно від компанії-постачальника. А офіційно — не було процедури. Попри те, що стягувати 50 гривень в тих умовах було абсурдно (опущу деталі заради кофіденційності), це просто було бюрократичне перенесення платежу на випадок, де він не мав будь-якого сенсу. Так ось, справа вирішилась лише тоді, коли дійшла до головного бухгалтеру. Хоча це взагалі не той рівень ні питання, ні ціни питання.
Чому? Бо була задача розробити процедуру. Яка виключає помилки (а це неможливо). І, якщо вона виключає помилки, то і реагування на помилки не має сенсу — їх же не має бути.
Сподіваюсь, ті, хто сприймав термін "управління помилками" іронічно, зараз зміг подивитись на це питання ширше — і отримав певну користь від прочитаного.
