در مورد یک پسر

داستان واقعی است، من همه چیز را به چشم خودم دیدم.

برای چندین سال، یک پسر، مانند بسیاری از شما، به عنوان برنامه نویس کار می کرد. در هر صورت، من آن را به این صورت می نویسم: "برنامه نویس". زیرا او 1Snik بود، در یک شرکت تولید تعمیر.

قبل از آن، او تخصص های مختلفی را امتحان کرد - 4 سال در فرانسه به عنوان برنامه نویس، مدیر پروژه، توانست 200 ساعت را تکمیل کند و در عین حال درصدی از پروژه را دریافت کند، برای مدیریت و فروش کمی. من سعی کردم به تنهایی محصولاتی را توسعه دهم، رئیس بخش فناوری اطلاعات در یک شرکت بزرگ با 6 هزار نفر بودم، گزینه های مختلفی را برای استفاده از حرفه قابل نقل قول خود امتحان کردم - برنامه نویس 1C.

اما همه این موقعیت ها عمدتاً از نظر درآمد تا حدودی بن بست بودند. در آن زمان همه ما تقریباً یک پول می گرفتیم و با یک شرایط کار می کردیم.

این مرد در تعجب بود که چگونه می تواند بدون فروش یا ایجاد کسب و کار خود پول بیشتری به دست آورد.

او خود را مردی باهوش تصور می کرد و تصمیم گرفت در شرکتی که در آن کار می کرد جایگاهی پیدا کند. این طاقچه باید چیز خاصی باشد و کسی آن را اشغال نکرده باشد. و من می خواستم خود شرکت بخواهد به شخصی در این طاقچه پول بپردازد تا نیازی به فریب کسی یا فریب چیزی نباشد. برای رسیدن به این هدف: فردی که در این موقعیت قرار دارد باید پول زیادی دریافت کند. عجیب و غریب، در یک کلام.

جستجو کوتاه مدت بود. در شرکتی که این مرد در آن کار می کرد، یک طاقچه کاملا رایگان وجود داشت که می توان آن را "به نظم درآوردن کارها در فرآیندهای تجاری" نامید. هر شرکتی مشکلات زیادی دارد. چیزی همیشه کار نمی کند و کسی نیست که بیاید و روند کسب و کار را درست کند. بنابراین، او تصمیم گرفت خود را به عنوان یک متخصص امتحان کند که می تواند به مالک در حل مشکلات خود در فرآیندهای تجاری کمک کند.

او در آن زمان شش ماه در این شرکت مشغول به کار بود و میانگین حقوق را در بازار دریافت می کرد. چیزی برای از دست دادن وجود نداشت، به خصوص که او می توانست به راحتی همان شغل را در عرض یک هفته پیدا کند. به طور کلی، این مرد تصمیم گرفت که اگر ناگهان هیچ چیز درست نشود و او اخراج شود، اتفاق بدی نمی افتد.

او جرات کرد و نزد صاحبش آمد. من به او پیشنهاد کردم که مشکل سازترین فرآیند را در تجارت بهبود بخشد. در آن زمان حسابداری انبار بود. اکنون همه کسانی که در این شرکت کار می کنند حتی از یادآوری آن مشکلات خجالت می کشند، اما موجودی هایی که به صورت فصلی انجام می شد، نشان دهنده مغایرت بین سیستم حسابداری و مانده های واقعی ده ها درصد بود. و از نظر هزینه و از نظر کمیت و تعداد موقعیت ها. این یک فاجعه بود. این شرکت در واقع تنها چهار بار در سال - یک روز پس از شمارش موجودی - موجودی صحیح را در سیستم حسابداری داشت. پسر ما شروع به نظم دادن به این روند کرد.

آن مرد با مالک موافقت کرد که باید انحرافات از نتایج موجودی را به نصف کاهش دهد. علاوه بر این ، مالک چیز خاصی برای از دست دادن نداشت ، زیرا قبل از قهرمان ما ، کارگران مختلفی قبلاً تلاش کرده بودند همه چیز را برطرف کنند و به طور کلی این کار عملاً غیرقابل حل تلقی می شد. همه اینها به شدت علاقه را برانگیخت، زیرا اگر همه چیز درست شود، آن شخص به طور خودکار تبدیل به فردی می شود که می داند چگونه کارها را مرتب کند و مشکلات غیر قابل حل را حل کند.

بنابراین، او با این وظیفه روبرو شد: کاهش انحرافات بر اساس نتایج موجودی تا 2 بار در یک سال. در شروع پروژه، او هیچ ایده ای برای رسیدن به این هدف نداشت، اما فهمید که حسابداری انبار یک چیز ساده است، بنابراین او هنوز هم می تواند کار مفیدی انجام دهد. علاوه بر این، کاهش انحرافات از ده ها درصد به یک ده درصد چندان دشوار به نظر نمی رسد. هر کسی که در مشاوره یا فعالیت های مشابه کار کرده است، می داند که اکثر مشکلات فرآیند را می توان با مراحل نسبتاً ساده حل کرد.

از ژانویه تا مه، او چیزی را آماده کرد، کمی خودکار کرد، فرآیند کسب و کار حسابداری انبار را بازنویسی کرد، جریان کاری انبارداران، حسابداران را تغییر داد و به طور کلی کل سیستم را بازسازی کرد، بدون اینکه چیزی را نشان دهد یا به کسی بگوید. در ماه مه، او دستورالعمل های جدیدی را بین همه توزیع کرد و پس از اولین موجودی سال، زندگی جدیدی آغاز شد - طبق قوانین او کار کرد. به منظور مشاهده نتایج، در آینده شرکت شروع به انجام موجودی بیشتر - هر دو ماه یک بار - کرد. در حال حاضر اولین نتایج مثبت بود و تا پایان سال، انحراف از نتایج حسابرسی به کسری از یک درصد کاهش یافت.

موفقیت بسیار بزرگ بود، اما نمی‌توان به پایداری آن باور داشت. خود آن مرد شک داشت که اگر کنار برود و از مشاهده روند دست بکشد، نتیجه حفظ شود. با این وجود ، نتیجه ای حاصل شد و آن مرد هر آنچه را که با مالک توافق کرد دریافت کرد. سپس، پس از چندین سال، ثبات نتیجه تأیید شد - برای چندین سال انحرافات در 1٪ باقی ماندند.

سپس تصمیم گرفت آزمایش را تکرار کند و به مالک پیشنهاد کرد که فرآیند مشکل ساز دیگری - عرضه را بهبود بخشد. کمبودهایی وجود داشت که به ما اجازه نمی داد حجم مورد نظر مشتریانمان را ارسال کنیم. ما توافق کردیم که ظرف یک سال کسری ها به نصف کاهش یابد و آن مرد همچنین 10-15 پروژه مربوط به 1C را تکمیل کند - تا فرآیندهای مختلف تجاری و سایر بدعت ها را خودکار کند.

در سال دوم، همه چیز دوباره با موفقیت تکمیل شد، کسری ها بیش از 2 برابر کاهش یافت، تمام پروژه های فناوری اطلاعات با موفقیت به پایان رسید.

از آنجایی که حقوق از قبل به مدت دو سال تمام نیازهای آن مرد را برآورده می کرد، او تصمیم گرفت کمی آرام بگیرد، آرام شود و در مکانی دنج و گرم که برای خودش ایجاد کرده بود بنشیند.

شبیه چه چیزی بود؟ او به طور رسمی مدیر فناوری اطلاعات بود. اما درک اینکه او واقعاً چه کسی بود دشوار است. بالاخره یک مدیر فناوری اطلاعات چه می کند؟ به عنوان یک قاعده، او زیرساخت فناوری اطلاعات را مدیریت می کند، مدیران سیستم را مدیریت می کند، یک سیستم ERP را پیاده سازی می کند و در جلسات هیئت مدیره شرکت می کند.

و این شخص یکی از مسئولیت های کلیدی برای مشارکت در فرآیندهای تغییر و عمدتاً تولید، شروع این فرآیندها، جستجو و پیشنهاد راه حل ها، بکارگیری تکنیک های مدیریت جدید، بررسی تغییرات پیشنهادی، تجزیه و تحلیل اثربخشی سایر عملکردها و تقسیمات، و در نهایت، مشارکت مستقیم در توسعه استراتژیک شرکت، تا توسعه مستقل یک برنامه استراتژیک برای کل شرکت.

به او کارت سفید داده شد. او می‌توانست به هر جلسه‌ای که قبلاً به آن دسترسی نداشت، بیاید. من آنجا با یک دفترچه یادداشت نشستم، چیزی یادداشت کردم یا فقط گوش دادم. او به ندرت صحبت می کرد. سپس او شروع به بازی با تلفن کرد و ادعا کرد که حافظه تداعی اینگونه بهتر کار می کند.

در جلسه او به ندرت چیز مفیدی ارائه کرد. او رفت، فکر کرد، سپس نامه ای رسید - یا با انتقاد، یا با نظر، یا با پیشنهاد، یا با شرح راه حل هایی که قبلاً اعمال کرده بود.

اما بیشتر اوقات خودش جلساتی را تشکیل می داد. من مشکلی را پیدا کردم، راه حل هایی ارائه دادم، علاقه مندان را شناسایی کردم و همه را به جلسه آوردم. و سپس - تا جایی که می توانست. او متقاعد کرد، انگیزه داد، ثابت کرد، استدلال کرد، به دست آورد.

او به طور غیررسمی بعد از مالک و مدیر، نفر سوم شرکت محسوب می شد. البته او با شروع از شماره 4 همه "افراد شرکت" را به طرز وحشتناکی خشمگین کرد. به خصوص با شلوار جین پاره و تی شرت های روشن و همچنین با مدتی که به عنوان مالک خود داشت.

صاحبش روزی 1 ساعت بهش وقت میداد. هر روز. آنها صحبت کردند، مشکلات، راه حل ها، کسب و کارهای جدید، زمینه های توسعه، شاخص ها و کارایی، توسعه شخصی، کتاب ها و زندگی ساده را مورد بحث قرار دادند.

اما این مرد عجیب بود. مثل این است که بنشینید و شاد باشید، زندگی خوب است. اما نه. تصمیم گرفت تامل کند.

او با تعجب پرسید: چرا این کار برای او انجام شد، اما دیگران این کار را نکردند؟ مالک نیز او را هل داد: او گفت که می خواهد دیگران نیز بتوانند نظم را برقرار کنند، زیرا مدیران زیادی وجود دارد، آنها به طور معمول درگیر مدیریت عملیاتی و برنامه ریزی استراتژیک هستند، اما عملا هیچ کس درگیر تغییرات سیستمی نیست. در فرآیندهای خود ممکن است در شرح وظایف آنها نوشته شده باشد که باید روند خود را سرعت بخشند و کارایی آن را افزایش دهند، اما در واقع هیچکس این کار را انجام نمی دهد. چرا اینطور است؟ آن پسر هم به دلیل علاقه مند شد و رفت تا با همه این مدیران صحبت کند.

او به معاونت کیفی مراجعه کرد و پیشنهاد کرد که نمودارهای کنترلی شوهارت معرفی شوند تا محصولات بهتر از ژاپنی ها باشند. اما معلوم شد که همکار نمی‌دانست نمودارهای کنترل شوهارت چیست، کنترل فرآیند آماری چیست و فقط درباره استفاده از چرخه دمینگ در مدیریت کیفیت شنیده بود. خوب…

او به یکی دیگر از معاونت ها مراجعه کرد و پیشنهاد کرد کنترل را معرفی کند. اما اینجا هم پشتیبانی پیدا نکردم. کمی بعد با مدیریت مرزها (مدیریت مرزی) آشنا شد و به همه معاونان پیشنهاد داد که بخش سیستمی این متدولوژی را به منظور بهبود فرآیندها اجرا کنند. اما مهم نیست که پسر ما چقدر صحبت می کرد، هیچ کس واقعاً نمی خواست در مورد چیستی آن تحقیق کند. شاید علاقه ای نداشتند یا خیلی سخت بود. اما در واقع هیچ کس آن را متوجه نشد.

به طور کلی، او در مورد همه چیزهایی که می دانست و در شرکت استفاده می کرد صحبت می کرد. اما هیچ کس او را درک نکرد. آنها هنوز نمی فهمند که چرا مثلاً در حسابداری انبار همه چیز اصلاح شد و کنترل و مدیریت مرزها چه ربطی به آن دارد.

آخر از همه، او به برنامه نویسان خود رسید - کارکنان شامل 3 نفر بودند. او در مورد مدیریت مرزها، در مورد کنترل، از مدیریت کیفیت، در مورد چابک و اسکرام صحبت کرد... و در کمال تعجب آنها همه چیز را درک کردند و حتی توانستند به نحوی با او بحث کنند، از جمله ظرافت های فنی و روش شناختی. آنها متوجه شدند که چرا پروژه های انبار و عرضه به نتیجه رسیدند. و سپس متوجه آن مرد شد: در واقع، برنامه نویسان جهان را نجات خواهند داد.

او متوجه شد که برنامه نویسان تنها کسانی هستند که می توانند فرآیندهای تجاری را به طور معمول و با جزئیات لازم درک کنند.

چرا آنها؟ در واقع، او هرگز پاسخ روشنی پیدا نکرد. من فقط نکات پایان نامه را فرموله کردم.

اولا، برنامه نویسان حوزه های موضوعی کسب و کار را می دانند و آنها را بهتر از سایر افراد شرکت می شناسند.

علاوه بر این، برنامه نویسان واقعاً درک می کنند که الگوریتم فرآیند چیست. این مهم است زیرا فرآیندهای تجاری الگوریتم هستند و عناصر موجود در آنها ممکن است به سادگی سازگار نباشند. به عنوان مثال، در فرآیند تدارکات که آن شخص روی آن کار می کرد، اولین مرحله ایجاد یک برنامه خرید سالانه بود و مرحله دوم خرید روزانه بود. این مراحل با یک اتصال مستقیم به هم متصل می شوند، یعنی فرض بر این است که افراد باید طبق این الگوریتم کار کنند - یک برنامه تدارکات سالانه تهیه کنند و بلافاصله درخواست را اجرا کنند. برنامه تدارکات سالانه یک بار در سال تنظیم می شود و درخواست ها 50 بار در روز دریافت می شود. اینجاست که الگوریتم به پایان می رسد و باید روی آن کار کنید. در واقع، او استدلال کرد، برای برنامه نویسان، دانش الگوریتم ها یک مزیت رقابتی است، زیرا هر کس دیگری که با آنها آشنا نیست به سادگی نمی داند که یک فرآیند تجاری چگونه باید کار کند و چگونه می توان آن را نشان داد.

یکی دیگر از مزایای برنامه نویسان، به گفته آن پسر، این است که آنها وقت آزاد کافی دارند. همه ما می دانیم که چگونه یک برنامه نویس می تواند سه برابر بیشتر از آنچه واقعاً نیاز دارد برای یک کار وقت بگذارد، و تعداد کمی متوجه می شوند. این، دوباره، یک مزیت رقابتی است، زیرا برای نظم بخشیدن به فرآیندهای تجاری، باید زمان آزاد زیادی داشته باشید - فکر کنید، مشاهده کنید، مطالعه کنید و تلاش کنید.

اکثر مدیران، به گفته پسر، این وقت آزاد را ندارند و به آن افتخار می کنند. اگر چه در واقع این بدان معنی است که یک فرد نمی تواند موثر باشد زیرا زمانی برای بهبود کارایی ندارد - یک دور باطل. در فرهنگ ما، شلوغ بودن مد شده است، بنابراین همه چیز ثابت می ماند. و برای ما برنامه نویسان این یک مزیت است. ما می توانیم وقت آزاد پیدا کنیم و به همه چیز فکر کنیم.

او گفت که برنامه نویسان می توانند به سرعت یک سیستم اطلاعاتی را تغییر دهند. این در همه شرکت ها قابل اجرا نیست، اما هر جا که کار می کرد، می توانست هر اصلاحی که می خواست انجام دهد. به خصوص اگر به کار شخص دیگری مربوط نباشد. به عنوان مثال، او می تواند سیستمی را راه اندازی کند که به طور مخفیانه اقدامات کاربر را اندازه گیری کند و سپس از این اطلاعات برای تجزیه و تحلیل کارایی همان بخش حسابداری و ردیابی هزینه های حسابداری استفاده کند.

و آخرین چیزی که از صحبت های او به یاد دارم این است که برنامه نویسان به حجم زیادی از اطلاعات دسترسی دارند، زیرا ... دسترسی اداری به سیستم داشته باشید. بنابراین می توانند از این اطلاعات در تحلیل خود استفاده کنند. هیچ کس دیگری در یک کارخانه معمولی چنین منبعی را ندارد.

و سپس او رفت. در طول بازداشت دو هفته ای لازم، او را مجبور کردیم که تجربه اش را در میان بگذارد، زیرا می خواستیم به کاری که انجام می داد ادامه دهیم. خب جایش خالی شد.

در طول چند روز او را روی صندلی نشاندند، دوربین را روشن کردند و مونولوگ هایش را ضبط کردند. آنها خواستند در مورد تمام پروژه های انجام شده، روش ها، رویکردها، موفقیت ها و شکست ها، علل و آثار، پرتره های مدیران و غیره به ما بگویند. هیچ محدودیت خاصی وجود نداشت، زیرا آنها نمی دانستند در سر او چه می گذرد.

مونولوگ ها، البته، اکثراً مزخرف و خنده بودند - او در خلق و خوی عالی بود، زیرا در حال ترک محوطه بیرونی به سمت سن پترزبورگ بود. برای کار در سن پترزبورگ کجا باید رفت؟ البته به گازپروم.

اما ما موفق شدیم از مونولوگ های او چیز مفیدی استخراج کنیم. آنچه را که به یاد دارم به شما می گویم.

بنابراین، توصیه های آن مرد. برای کسانی که می خواهند تلاش کنند تا همه چیز را در فرآیندهای تجاری مرتب کنند.

برای انجام این نوع کار، ابتدا باید سطح مشخصی از "یخ زدگی" داشته باشید. شما نباید از از دست دادن شغل خود بترسید، از ریسک کردن نترسید، از درگیری با همکاران نترسید. این برای او آسان بود، زیرا او زمانی سفر خود را آغاز کرد که تنها شش ماه در شرکت کار کرده بود و فرصتی برای تماس با کسی نداشت و قصد انجام این کار را نداشت. او فهمید که مردم می‌آیند و می‌روند، اما نتایج خودش و ارزیابی‌شان توسط صاحب کسب‌وکار برایش مهم است. اینکه همکارانش با او خوب یا بد رفتار می‌کردند، در آن زمان برایش اهمیت چندانی نداشت.

نکته دوم اینکه برای انجام موثر این کار متاسفانه باید مطالعه کنید. اما نه برای MBA، نه در دوره ها، نه در موسسات، بلکه به تنهایی مطالعه کنید. به عنوان مثال، در اولین پروژه خود، یک پروژه انبار، او به طور شهودی عمل کرد، او چیزی نمی دانست، فقط "مدیریت کیفیت" چیست.

هنگامی که او شروع به خواندن ادبیات در مورد روش های افزایش کارایی کرد، فناوری هایی را که استفاده می کرد کشف کرد. آن مرد آنها را به طور شهودی به کار برد، اما معلوم شد که این اختراع او نبوده است، همه چیز از قبل نوشته شده بود. اما او زمان صرف کرد، و خیلی بیشتر از اینکه بلافاصله کتاب مناسب را خوانده باشد. در اینجا فقط درک این نکته مهم است که وقتی یک تکنیک خاص را مطالعه می کنید، هیچ یک از آنها، حتی پیشرفته ترین آنها، به طور کامل تمام مشکلات یک فرآیند تجاری را حل نمی کند.

ترفند دوم این است که هر چه تکنیک های بیشتری بلد باشید، بهتر است. به عنوان مثال، در ژاپن باستان، میاموتو موساشی، یکی از مشهورترین شمشیربازان، نویسنده سبک دو شمشیر زندگی می کرد. او در مدرسه ای نزد استادی درس خواند، سپس به سراسر ژاپن سفر کرد، با افراد مختلف جنگید. اگر آن مرد قوی تر بود، پس سفر برای مدتی متوقف شد و موساشی دانشجو شد. در نتیجه، طی چندین سال او مهارت‌های تمرین‌های مختلف اساتید مختلف را به دست آورد و مدرسه خود را تشکیل داد و چیزی از خود اضافه کرد. در نتیجه، او به یک مهارت منحصر به فرد دست یافت. اینجا هم همینطوره

البته می توانید به عنوان مشاور کسب و کار عمل کنید. در کل، آنها بچه های خوبی هستند. اما قاعدتاً می آیند نوعی متدولوژی را معرفی می کنند و متدولوژی اشتباهی را که مورد نیاز کسب و کار است پیاده می کنند. ما همچنین چنین موقعیت های غم انگیزی داشتیم: هیچ کس نمی داند چگونه مشکل را حل کند و هیچ کس نمی خواهد فکر کند که چگونه آن را حل کند. یا در اینترنت شروع به جستجو می کنیم یا با مشاور تماس می گیریم و از او می پرسیم چه چیزی می تواند به ما کمک کند. مشاور فکر می کند و می گوید باید نظریه محدودیت ها را معرفی کنیم. ما برای توصیه او به او پول می دهیم، برای اجرا هزینه می کنیم، اما نتیجه صفر است.

چرا این اتفاق می افتد؟ چون مشاور گفت ما فلان سیستم را معرفی می کنیم و همه با او موافق بودند. عالی است، اما یک روش همه مشکلات حتی یک فرآیند تجاری را پوشش نمی دهد، به خصوص اگر پیش نیازهای اولیه - ما و موارد مورد نیاز برای اجرای روش - مطابقت نداشته باشند.

در تمرینی که آن مرد توصیه می کند، باید بهترین ها را بگیرید و بهترین ها را اجرا کنید. روش ها را به طور کامل در نظر نگیرید، بلکه ویژگی ها، ویژگی ها و شیوه های کلیدی آنها را در نظر بگیرید. و مهمترین چیز این است که ماهیت را درک کنید.

او گفت، برای مثال، اسکرام یا چابک را در نظر بگیرید. در مونولوگ های خود ، آن مرد بارها تکرار کرد که همه جوهر اسکرام را کاملاً درک نمی کنند. او همچنین کتاب جف ساترلند را خواند که برخی از مردم آن را "خواندن سبک" می دانند. برای او خواندنی عمیق به نظر می رسید، زیرا یکی از اصول اساسی اسکرام مدیریت کیفیت است، این به طور مستقیم در کتاب نوشته شده است.

در مورد تولید تویوتا می گوید، در مورد اینکه چگونه جف ساترلند اسکرام را در ژاپن نشان داد، چگونه در آنجا ریشه گرفت و چقدر به فلسفه آنها نزدیک بود. و ساترلند در مورد اهمیت نقش اسکرام مستر، در مورد چرخه دمینگ صحبت کرد. نقش اسکرام مستر سرعت بخشیدن مداوم به فرآیند است. هر چیز دیگری که در اسکرام وجود دارد - تحویل مرحله‌ای، رضایت مشتری، فهرست روشنی از کار برای دوره‌ی اسپرینت - نیز مهم است، اما همه این‌ها باید سریع‌تر و سریع‌تر حرکت کنند. سرعت کار باید دائماً در واحدهایی که در آن اندازه گیری می شود افزایش یابد.

شاید این موضوع ترجمه باشد، زیرا کتاب ما به عنوان "اسکرام - روش انقلابی مدیریت پروژه" ترجمه شده است، و اگر عنوان انگلیسی به معنای واقعی کلمه ترجمه شود، معلوم می شود: "اسکرام - دو برابر در نیمی از زمان" ، یعنی حتی در نام به سرعت به عنوان یک تابع کلیدی اسکرام اشاره می کند.

وقتی این مرد اسکرام را پیاده سازی کرد، سرعت در ماه اول بدون هیچ تغییر قابل توجهی دو برابر شد. او نقاطی را برای تغییر پیدا کرد و خود اسکرام را اصلاح کرد تا آن را بسیار سریعتر کار کند. تنها چیزی که در اینترنت می نویسند این است که با این سوال مواجه شده اند: "ما سرعت را دو برابر کرده ایم، تنها چیزی که می ماند این است که بفهمیم با چنین سرعتی چه می کنیم؟" با این حال، این یک منطقه کاملا متفاوت است ...

او همچنین شخصاً چندین تکنیک را توصیه کرد. او آنها را بنیادی و اساسی خواند.

اولین مورد مدیریت مرزها است.

آنها آن را در Skolkovo آموزش می دهند؛ به گفته آن مرد، هیچ کتاب و مواد دیگری وجود ندارد. او به نوعی خوش شانس بود که در سخنرانی استادی از هاروارد که مدیریت مرزها را موعظه می کرد شرکت کرد و همچنین چندین مقاله در هاروارد بیزینس ریویو در مورد کار اریک تریست خواند.

مدیریت مرز می گوید که شما باید بتوانید مرزها را ببینید و با مرزها کار کنید. مرزهای زیادی وجود دارد، آنها همه جا هستند - بین بخش ها، بین انواع مختلف کار، بین کارکردها، بین کار عملیاتی و تحلیلی. دانش مدیریت مرز هیچ حقیقت بالاتری را آشکار نمی کند، اما به ما اجازه می دهد تا واقعیت را در نور کمی متفاوت ببینیم - از طریق منشور مرزها. و، بر این اساس، آنها را مدیریت کنید - آنها را در جایی که لازم است نصب کنید، و آنها را در جایی که سر راه هستند حذف کنید.

اما بیشتر اوقات آن مرد در مورد کنترل صحبت می کرد. او فقط در مورد این موضوع نوعی ابهام داشت.

به طور خلاصه، کنترل، مدیریت مبتنی بر اعداد است. در اینجا، او گفت، هر بخش از تعریف مهم است - هم "مدیریت" و هم "بر اساس" و "اعداد".

گفت ما با هر سه مولفه کنترل بد هستیم. مخصوصاً با توجه به اینکه آنها هم با یکدیگر و هم با سایر بخش‌های سیستم کسب و کار ارتباط تنگاتنگی دارند.

اولین چیزی که بد است اعداد است. تعداد آنها کم است و کیفیت پایینی دارند.

سپس بخش قابل توجهی از اعداد را از سیستم اطلاعاتی 1C گرفتیم. بنابراین، کیفیت اعداد در 1C، همانطور که او ادعا کرد، خوب نیست. حداقل به دلیل قابلیت تغییر داده ها به صورت عطف به ماسبق.

واضح است که این تقصیر توسعه دهندگان 1C نیست - آنها فقط الزامات بازار و ذهنیت حسابداری داخلی را در نظر می گیرند. اما برای اهداف کنترلی، بهتر است اصول کار 1C با داده ها را در یک شرکت خاص تغییر دهید.

علاوه بر این، به گفته وی، اعداد از 1C، به عنوان مثال، با استفاده از Excel تحت پردازش نیمه دستی قرار می گیرند. چنین پردازشی همچنین کیفیت و کارایی را به داده ها اضافه نمی کند.

در پایان شخص دیگری گزارش نهایی را مجدداً بررسی می کند تا تصادفاً ارقام دارای خطا را به مدیر ارسال نکند. در نتیجه، اعداد زیبا، تایید شده، اما بسیار دیر به دست گیرنده می رسد. معمولا - پس از پایان دوره (ماه، هفته، و غیره).

و در اینجا، او گفت، همه چیز بسیار ساده است. اگر اعداد مربوط به ژانویه در ماه فوریه به شما رسید، دیگر نمی توانید فعالیت های ژانویه را مدیریت کنید. چون ژانویه تمام شده است.

و اگر ارقام بر اساس حسابداری باشد و شرکت معمولی ترین شرکت با ارائه سه ماهه مالیات بر ارزش افزوده باشد، مدیر آن هر سه ماه یک بار ارقام نسبتاً مناسبی را دریافت می کند.

بقیه اش مشخص است. شما یک بار در ماه اعداد را دریافت می کنید - این فرصت را دارید که 12 بار در سال با اعداد (یعنی کنترل) مدیریت کنید. اگر گزارش دهی فصلی را تمرین می کنید، سالی 4 بار آن را مدیریت می کنید. به علاوه یک جایزه - گزارش سالانه. یک بار دیگر هدایت کنید.

در بقیه زمان‌ها، کنترل معمولاً کورکورانه انجام می‌شود.

وقتی (و اگر) اعداد ظاهر شوند، مشکل دوم مطرح می شود - چگونه بر اساس اعداد مدیریت کنیم؟ من نمی توانستم با این نکته از استدلال او موافق باشم.

آن مرد استدلال کرد که اگر مدیر قبلاً اعداد را نداشته باشد، ظاهر آنها باعث ایجاد یک اثر شگفت انگیز می شود. او اعداد را این‌طرف و آن طرف نگاه می‌کند و می‌پیچد، مردم را روی فرش صدا می‌کند، توضیح و تحقیق می‌خواهد. پس از بازی با اعداد، انجام تجزیه و تحلیل و تهدید تهدیدآمیز به همه کارمندان که "حالا از شر شما خلاص نمی شوم"، مدیر خیلی سریع آرام می شود و از این موضوع دست می کشد. استفاده از ابزار را متوقف کنید. اما مشکلات به قوت خود باقی خواهند ماند.

او گفت که این اتفاق به دلیل شایستگی های مدیریتی ناکافی است. در کنترل، اول از همه. مدیر به سادگی نمی داند با این اعداد چه کند. چی сانجام دهد - می داند چه باید بکند - نه. انجام دادن همان چیزی است که در بالا نوشته شده است (مشاهده کردن، بازی کردن). انجام یک فرآیند کسب و کار روزانه است.

او استدلال کرد که همه چیز بسیار ساده است: دیجیتال باید بخشی از فرآیند کسب و کار شود. در فرآیند کسب و کار باید به وضوح مشخص شود: چه کسی باید چه کاری را انجام دهد و چه زمانی در صورت انحراف اعداد از هنجار (هر گزینه - بالای مرز، زیر مرز، فراتر رفتن از راهرو، وجود یک روند، عدم رعایت چندک و غیره)

و بنابراین او معضل کلیدی را تشریح کرد: تعداد وجود دارد، باید بخشی از سیستم تجاری شود تا کارایی مدیریت افزایش یابد، اما... این اتفاق نمی افتد. چرا؟

زیرا رهبر روسیه ذره ای از قدرت خود را به رقیب واگذار نخواهد کرد.

رقبای مدیر روسی - یک فرآیند تجاری با کیفیت و کارآمد، انگیزه متقابل سودمند و اتوماسیون مناسب - متأسفانه، مدیر را بدون شغل رها می کنند.

یه جور مزخرف، موافق نیستی؟ به خصوص در مورد رهبران. باشه بهت گفتم خودت تصمیم بگیر

کمی کمتر، اما باز هم زیاد، به نظر من، او در مورد اسکرام صحبت کرد.

گفتم مطمئن باشید اسکرام را در عمل بخوانید و امتحان کنید. او می گوید، اگر آن را خوانده اید اما امتحان نکرده اید، خود را نادان بدانید. بهتر است به جای مقالات و انواع راهنماها در اینترنت، مثلاً از ساترلند، یک کتاب بخوانید.

او گفت که اسکرام فقط از طریق تمرین و با اندازه گیری های اجباری میزان کار انجام شده قابل یادگیری است. شخصاً دو نقش مهم را امتحان کنید - مالک محصول و اسکرام مستر.

به گفته این مرد، تجربه در عمل نقش یک اسکرام مستر بسیار مهم است، زمانی که می توانید حجم کارهای انجام شده در هر اسپرینت را بدون افزایش منابع و هزینه اسپرینت افزایش دهید.

خوب، در بالای او TOS (نظریه محدودیت های سیستم) وجود داشت.

به گفته این مرد، اینها اصول اساسی و اساسی افزایش کارایی هستند که می توانند تقریباً در هر زمینه، در هر فرآیند تجاری و سیستم تجاری به طور کلی اعمال شوند.

وقتی فهمید که ما با TOS آشنا نیستیم، دیگر به ما نگفت. او فقط اضافه کرد که ما را از لذت خواندن کتاب های الیاهو گلدرات محروم نمی کند. او توصیه مشابهی به اسکرام داد - آن را بخوانید و امتحان کنید. به عنوان مثال، مهم نیست در چه موقعیتی هستید، هر کاری که انجام می دهید، جایی برای افزایش کارایی با استفاده از روش های TOC وجود دارد.

سپس کوله بار تکنیک های او ظاهراً خشک شد و گفت: اصول را با هم ترکیب کنید تا در یک موقعیت خاص راه حل های کاربردی ایجاد کنید.

او می گوید، این توصیه اصلی، کلید موفقیت است. درک اصول، ماهیت، و ایجاد راه حل های کاربردی منحصر به فرد - فرآیندهای تجاری و سیستم های تجاری.

سپس سعی کرد نقل قولی را به خاطر بسپارد و در پایان مجبور شد آنلاین شود. معلوم شد که این نقل قولی از مقاله "ایستادن بر شانه های غول ها" نوشته الیاهو گلدرات است:

«بین راه‌حل‌های کاربردی (کاربردها) و مفاهیم اساسی که آن راه‌حل‌ها بر آن‌ها استوار شده‌اند، تفاوت وجود دارد. مفاهیم کلی هستند، راه حل های کاربردی انطباق مفاهیم با یک محیط خاص است. همانطور که قبلاً دیدیم، چنین سازگاری ساده نیست و نیاز به توسعه عناصر خاصی از راه حل دارد. باید به خاطر داشته باشیم که یک راه حل کاربردی مبتنی بر فرضیات اولیه (گاهی اوقات پنهان) در مورد یک محیط خاص است. نباید انتظار داشت که این راه حل کاربردی در محیطی کار کند که مفروضات آن درست نیست."

او گفت که کار یک برنامه نویس و یک "بهبود فرآیند کسب و کار" بسیار شبیه است. و رفت.

منبع: www.habr.com