در جلسهٔ یک کلینیک، مسئول پذیرش می‌گوید: «بعضی‌ها نوبتشان را لغو می‌کنند و می‌گویند هفتهٔ بعد با آن‌ها تماس بگیریم، ولی وسط کارها یادمان می‌رود.» مدیر پیشنهاد می‌دهد از این به بعد، برای هرکدام مشخص کنند چه کسی باید تماس بگیرد و چه روزی. تصمیم خوبی است و اجرای آن هم ظاهراً سخت نیست.
اما وقتی به نرم‌افزار برمی‌گردند، فقط می‌توانند نوبت را «لغوشده» ثبت کنند. جایی برای تاریخ تماس بعدی یا نام مسئول پیگیری وجود ندارد. مسئول پذیرش یک فایل جدا باز می‌کند و اسم‌ها را آنجا می‌نویسد. حالا برای فهمیدن وضعیت یک مراجعه‌کننده، باید هم نرم‌افزار را نگاه کنند، هم فایل را و گاهی هم پیام‌های همکاران را.
این مثال فرضی، اتفاقی آشنا در کسب‌وکارهاست. تیم در کار روزانه متوجه می‌شود که باید چیزی را بهتر انجام دهد، اما نرم‌افزار هنوز با روش قبلی کار می‌کند. تا وقتی امکان تغییر آن فراهم شود، تصمیم تازه با یادداشت، فایل و هماهنگی دستی اجرا می‌شود.
حالا تصور کنید مدیر بتواند همان چیزی را که در جلسه گفته، برای نرم‌افزار هم توضیح بدهد: «وقتی کسی نوبتش را لغو می‌کند و پیگیری می‌خواهد، ثبت کنیم چه کسی باید با او تماس بگیرد و چه روزی. آن روز هم این کار در فهرست کارهای مسئولش دیده شود.»
اگر سیستم بتواند این درخواست را بفهمد و تغییر لازم را آماده کند، تصمیم جلسه جای مشخصی در کار روزانه پیدا می‌کند. مسئول پذیرش اطلاعات پیگیری را کنار همان نوبت ثبت می‌کند و همکارش در روز تعیین‌شده می‌بیند که باید با چه کسی تماس بگیرد. دیگر لازم نیست برای اجرای این تصمیم، یک فهرست جدا را هم مرتب به‌روز کنند.
لازم نیست کاربر زبان نرم‌افزار را بلد باشد
مدیر کلینیک می‌داند چه مشکلی دارد: پیگیری‌ها فراموش می‌شوند. او می‌تواند توضیح بدهد که تیمش چطور می‌خواهد این مشکل را حل کند، حتی اگر نداند در نرم‌افزار چه بخش‌هایی باید تغییر کنند.
امکان تغییر سیستم با زبان طبیعی، از همین‌جا معنا پیدا می‌کند. کاربر نیازش را با زبان معمولی بیان می‌کند و سیستم کمک می‌کند آن نیاز به چیزی قابل‌استفاده تبدیل شود. مثلاً برای مسئول پذیرش، جای ثبت تاریخ و مسئول تماس فراهم شود و برای همکار دیگر، فهرست پیگیری‌های روزانه.
این گفت‌وگو احتمالاً با یک جمله تمام نمی‌شود. سیستم باید بپرسد: «چه کسی مسئول تماس را انتخاب می‌کند؟» یا «اگر مراجعه‌کننده پیش از موعد تماس، نوبت تازه گرفت، با پیگیری قبلی چه کنیم؟» پاسخ این سؤال‌ها را تیم می‌دهد، چون روش کار و مسئولیت‌ها را آدم‌های همان کسب‌وکار تعیین می‌کنند.
بعد از روشن‌شدن این موارد، سیستم باید نشان بدهد که نتیجه چه خواهد بود. مسئول پذیرش چه چیزی می‌بیند؟ کار تماس کجا ظاهر می‌شود؟ چه کسی می‌تواند آن را انجام‌شده ثبت کند؟ تیم می‌تواند با چند نمونه امتحان کند و اگر چیزی درست نبود، پیش از استفادهٔ روزانه اصلاحش کند.
آسان‌ترشدن تغییر نباید کنترل را از بین ببرد
اگر بتوان با گفت‌وگو نرم‌افزار را تغییر داد، باید معلوم باشد چه کسی اجازهٔ این کار را دارد. ممکن است مسئول پذیرش بتواند تاریخ تماس را ثبت کند، اما اجازهٔ تغییر روش پیگیری برای همهٔ کارکنان را نداشته باشد. هر همکار هم باید فقط اطلاعاتی را ببیند که برای کارش به آن نیاز دارد.
تغییر پیشنهادی باید پیش از اجرا به تأیید فرد مسئول برسد. همچنین باید ثبت شود که چه کسی، چه زمانی و چه چیزی را تغییر داده است. اگر چند روز بعد مشکلی پیش آمد، مدیر بتواند بفهمد چه اتفاقی افتاده و برای اصلاح آن تصمیم بگیرد. امکان برگشت به روش قبلی هم باید روشن باشد، با توجه به کارهایی که در این فاصله انجام شده‌اند.
همین دقت دربارهٔ ایجنت‌ها هم لازم است. اضافه‌کردن پیگیری به سیستم، به‌خودی‌خود به معنی اجازهٔ ارسال پیام به مراجعه‌کننده نیست. اگر قرار باشد ایجنت پیام بفرستد یا کاری را خودکار انجام دهد، حدود دسترسی و نیاز به تأیید آن باید جداگانه مشخص شود.
ارزش این تغییر، در روز کاری دیده می‌شود
برای تیم کلینیک، نتیجه قرار است ساده باشد: کسی که درخواست تماس دوباره داشته، فراموش نشود؛ مسئول پیگیری بداند چه کاری دارد و مدیر بتواند وضعیت را بدون پرس‌وجو از چند نفر ببیند.
مثلاً ممکن است تیم بعداً بخواهد بداند چرا مراجعان نوبتشان را لغو می‌کنند. در این صورت، باید بتواند گزینهٔ ثبت علت لغو را هم به همان بخش اضافه کند. کسب‌وکار در طول کار یاد می‌گیرد و روشش را اصلاح می‌کند. سیستم مدیریتی هم باید امکان همراه‌شدن با این یادگیری را داشته باشد.
البته نرم‌افزار نمی‌تواند جای تصمیم‌گیری تیم را بگیرد. اگر هنوز معلوم نیست مسئول تماس چه کسی است، ساختن بخش پیگیری این ابهام را حل نمی‌کند. ابتدا باید روش کار روشن شود؛ بعد سیستم می‌تواند کمک کند آن را منظم‌تر اجرا کنند.
هم‌برد به کدام سمت می‌رود؟
هم‌برد مسیری را دنبال می‌کند که در آن داده‌ها، فرایندها، ابزارها و ایجنت‌ها در یک بستر عملیاتی مشترک قرار بگیرند و سیستم مدیریتی بتواند با روش واقعی کار کسب‌وکار تغییر کند. فرم‌ها، قواعد و بخش‌های مختلف سیستم قرار نیست برای همیشه به شکل روز اول باقی بمانند.
مثال این مقاله، تصویری از این جهت‌گیری است؛ نه ادعای آماده‌بودن کامل تغییر سیستم با زبان طبیعی در محصول فعلی. مسیر فعلی هم‌برد از اتصال و یکپارچگی شروع می‌شود، سپس به ایجنتی در پنل می‌رسد که با درخواست کاربر کار انجام می‌دهد و در ادامه، به ایجنت‌های حلقه‌ای و خودکار می‌رسد که بر اساس رویدادها اقدام می‌کنند. انسان و ایجنت در این بستر با داده‌ها و ابزارهای مشترک کار می‌کنند. امکان ساختن و تغییر سیستم با گفت‌وگو نیز باید به‌تدریج و با کنترل روشن شکل بگیرد.
برای مدیر کلینیک، همهٔ این بحث‌ها به یک خواستهٔ مشخص برمی‌گردد: «ما فهمیده‌ایم چطور بهتر کار کنیم؛ حالا می‌خواهیم نرم‌افزار هم با این روش همراه شود.» اگر فاصلهٔ میان این تصمیم و اجرای آن کوتاه‌تر شود، هر بهبود کوچک دیگر به یک فایل تازه ختم نمی‌شود. می‌تواند بخشی از خود سیستم شود و همراه با کسب‌وکار رشد کند.