اگر یک واحد نیاز به محصول دارد و واحد دیگری اطلاعات صدور فاکتور را هماهنگ میکند، این دو مسیر را در درخواست خرید جدا بنویسید. شرح نیاز، تأیید ادامه خرید و اطلاعات صدور سند سه ورودی متفاوتاند. داشتن نام کاربر محصول، اجازه صدور سند با اطلاعات حدسی یا اعلام شروع اجرا نیست.
برگه درخواست را با سه ورودی مستقل بسازید
ورودی اول شرح خدمت موردنیاز و نسخه پیشنهاد است؛ ورودی دوم اعلام ادامه خرید از مسیر مجاز سازمان؛ ورودی سوم اطلاعاتی است که تیم فروش برای صدور سند خواسته است. هر کدام وضعیت دریافت و مسئول هماهنگی جدا دارد. وقتی یکی کامل شد، بقیه را خودکار کامل نکنید. مثال آموزشی: تیم پشتیبانی بسته را انتخاب کرده، اما واحد اداری هنوز اطلاعات لازم را تأیید نکرده است؛ وضعیت درست آماده صدور نیست.
واحد استفادهکننده، دامنه را توضیح میدهد
در نمونه، واحد پشتیبانی میگوید خدمت روی کدام سایت و برای چه پرسشهایی لازم است. این داده برای بررسی تناسب مهم است، ولی عنوان حقوقی گیرنده سند از آن به دست نمیآید. در فرم، شرح استفاده را با مشخصات صدور در یک خانه ننویسید. از تیم فروش بپرسید چه اطلاعاتی و از چه مسیر رسمی لازم است. این مقاله شکل حقوقی سند یا الزامات مالیاتی آن را تعیین نمیکند و جای بررسی مسئولان مجاز نیست.
گیرنده سند را با هماهنگکننده اجرا مخلوط نکنید
واحد اداری ممکن است فقط فاکتور را دریافت کند؛ سؤالهای فنی باید همچنان به فرد معرفیشده برای دامنه برگردند. یک فهرست مقصد داشته باشید که نوع پیام، نقش گیرنده و منبع تأیید مسیر را نشان دهد. همه سندها را برای همه افراد نفرستید تا شاید نفر درست پیدا شود. داده محرمانه و رمز جایی در این برگه ندارند؛ فقط نقش و کانال مجاز لازم برای همان مرحله ثبت میشود.
تغییر هر ورودی، کنترل مربوط خودش را باز میکند
اگر فقط هماهنگکننده اداری عوض شد، معلوم کنید روش معرفی جایگزین و دریافت سند چیست؛ لزوماً دامنه فنی عوض نشده است. اگر بسته تغییر کرد، نسخه پیشنهاد و جمعبندی خرید دوباره باید کنترل شوند. اگر مشخصات صدور تغییر کرد، به تیم فروش اعلام کنید کدام سند و کدام اطلاعات نیاز به بررسی دارد. اصلاح را شخصاً روی نسخه سند فروشنده انجام ندهید و فایل دستکاریشده را مبنای قطعی پرداخت قرار ندهید.
خروجی برگه، یک درخواست بدون ابهام است
نمونه پیام: «برای خدمت مندرج در نسخه Q-02 ادامه بررسی خرید را میخواهیم. شرح استفاده توسط نقش فنی تأیید شده؛ اطلاعات صدور از مسیر اداری معرفیشده تکمیل میشود. لطفاً موارد باقیمانده و روش رسمی دریافت فاکتور را اعلام کنید.» این پیام نه تأیید پرداخت است و نه اعلام فعالشدن خدمت. پس از صدور، لینک پرداخت از مسیر واقعی تیم فروش و شروع اجرا طبق توافق دنبال میشود. در تمرین، یک ورودی ناقص بگذارید و بررسی کنید آیا تیم بدون حدسزدن دادهها، همان نقص را به صاحب مناسب برمیگرداند.
فرم نقشهای خرید سازمانی؛ نمونه آموزشی
دادههای جدول زیر ساختگیاند و نتیجه اجرای واقعی هیچ محصولی نیستند. آنها را برای تمرین تیم به کار ببرید و قواعد اجرایی را با مسئول همان فرایند تأیید کنید.
| ورودی درخواست آموزشی | صاحب هماهنگی | مدرک لازم | وضعیت مستقل |
|---|---|---|---|
| شرح خدمت | واحد استفادهکننده | نسخه دامنه مورد توافق | تأیید یا سؤال باز |
| ادامه خرید | مسیر مجاز خرید سازمان | ارجاع به همان نسخه پیشنهاد | اعلام شده یا باز |
| اطلاعات صدور | واحد معرفیشده برای سند | فهرست رسمی خواستهشده توسط فروش | کامل یا ناقص |
| هماهنگی اجرا | نماینده معرفیشده اجرا | پیشنیاز و زمان توافقشده | مرحله بعد از فرایند فروش |
دانلود فرم نقشهای خرید سازمانی با قالب CSV سازگار با اکسل. فایل از داده آموزشی تشکیل شده و اطلاعات مشتری واقعی ندارد. پیش از استفاده عملی، عنوان ستونها و مقادیر مجاز را با سامانه خودتان تطبیق دهید.
منبع و ادامه مسیر
در مدل RACI مستند Atlassian، نقشها برای فعالیتهای متفاوت جدا میشوند. Our Atlassian Security Incident Responsibilities. این ارجاع، روش اختصاصی این مقاله یا قابلیت اپرا را گواهی نمیکند؛ روش و مثالهای بالا پیشنهاد تحریریه برای طراحی و آزمون هستند.
برای زمینه مرتبط، مخاطب تصمیمگیرنده نیست؛ پیگیری فروش را چگونه ادامه دهیم؟ و قبل از ارسال پیشنهاد فروش چه چیزهایی را بررسی کنیم؟ را بخوانید. اگر دنبال راهکار اجرایی هستید، بستهها و مسیر درخواست پیشنهاد اپرا را بررسی کنید؛ امکان اجرای سناریوی خود را با تیم فروش مشخص کنید. انتخاب بسته به معنی ثبت خودکار درخواست، صدور فاکتور یا فعالشدن فوری خدمت نیست.
راهنماهای مرتبط با این مسئله
از انتخاب بسته تا لینک پرداخت؛ درخواست فاکتور را چطور کامل کنیم؟ و مسئول هر کار در راهاندازی کیست؟ نمونه ماتریس مسئولیت پروژه میتوانند گام بعدی بررسی تیم شما باشند.