API

1- ای پی آی چیست؟

ای پی آی مخفف اصطلاح رابط برنامه‌نویسی کاربردی (Application Programming Interface) است.

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

یک API صرفاً رابطی میان دو موجودیت پیاده‌سازی‌شده است. به صورت کلی، API موجودیتی است که بتواند دو کار را انجام دهد:

اول، باید مجموعه‌ای از عملیات را به وسیله ورودی‌ها و خروجی‌ها انجام دهد؛

دوم، باید امکان پیاده‌سازی مجدد را بدون تأثیرگذاری بر کاربران فراهم نماید.

ای پی آی ها را می‌توان در دو دسته کلی جای داد:

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

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

2- جنبه های قابل بررسی APIها

بر اساس سیاست های انتشار

• ای پی آی های خصوصی(Private APIs)

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

• ای پی آی های شراکتی (Partner APIs)

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

• ای پی آی های اعضا (Member APIs)

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

• ای پی آی های همکاری (Acquaintance APIs)

این نوع APIهای باز فراگیر هستند. چرا که برای همه اشخاصی که با مجموعه ملزومات از پیش تعریف شده موافقند باز هستند. درگاه‌های ارائه دهنده این نوع API را که با برخی از اشکال توافقنامه‌های استاندارد همراه است، توزیع می‌کنند. دسترسی تجاری به APIهای مناطق فروش(POS) مثالی از این نوع می‌باشد.

• ای پی آی های عمومی (Publice APIs)

این APIها، که به APIهای بیرونی نیز معروف هستند، برای هر توسعه‌دهنده‌ و نهاد ثالثی دردسترس هستند. APIهای عمومی، اگر به درستی عرضه شوند، امکان افزایش آگاهی از برند و بهره‌گیری از منبع درآمدی جدید را برای شرکت فراهم می‌کنند.

دو نوع از APIهای عمومی وجود دارند:

APIهای باز (رایگان) و APIهای تجاری.

- APIهای باز، کاملاً عمومی بوده و بدون هرگونه شرایط و مقررات محدودکننده‌ای، قابل استفاده هستند. برای مثال، می‌توان اپلیکیشنی را با استفاده از APIها، بدون نیاز به اخذ تأییدیه از منتشرکننده آن یا پرداخت هزینه حق اشتراک، طراحی نمود.

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

 ای پی آی ها بر اساس موارد استفاده

ای پی آی ها را می‌توان بر اساس نوع سیستم‌هایی که APIها برای آن‌ها ساخته می‌شوند، دسته‌بندی نمود.

• ای پی آی های پایگاه داده

ای پی آی های پایگاه داده، ارتباط میان یک اپلیکیشن و یک سیستم مدیریت پایگاه داده را برقرار می‌نمایند. توسعه‌دهندگان به وسیله نوشتن کوئری‌هایی برای دسترسی به داده‌ها، تغییر جداول و سایر اقدامات مشابه، با پایگاه‌های داده کار می‌کنند. برای مثال، API پایگاه داده The Drupal، به کاربران این امکان را می‌دهد تا کوئری‌های یکتا و واحدی را برای پایگاه‌‌های داده متفاوت، بنویسند.

مثال دیگر، API پایگاه داده ORDS است که درون Oracle REST Data Services، تعبیه شده است.

• ای پی آی ها ی سیستم‌عامل

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

• ای پی آی های ریموت

این APIها، استانداردهایی را برای تعامل اپلیکیشن‌هایی که بر روی دستگاه‌های متفاوت راه‌اندازی شده‌اند، تعریف می‌کنند. به بیان دیگر، یکی از اپلیکیشن‌ها، به منابعی که خارج از دستگاهی که بر روی آن قرار دارد، دسترسی پیدا می‌کند. از آنجایی که دو اپلیکیشن از طریق یک شبکه ارتباطی (معمولاً اینترنت)، با یکدیگر در ارتباط هستند، بیشتر APIهای ریموت، مبتنی بر استانداردهای وب، نوشته شده‌اند. Java Database Connectivity API و Java Remote Method Invocation API، دو نمونه از APIهای ریموت هستند.

• ای پی آی های تحت وب

این نوع از APIها، متداول‌ترین نوع API، هستند. APIهای تحت وب، داده‌های قابل خوانش توسط ماشین و امکان انتقال آن‌ها میان سیستم‌های تحت وب را فراهم می‌کنند. این APIها، معمولاً درخواست‌های اپلیکیشن‌های تحت وب را به سرورها و پاسخ سرورها به اپلیکیشن‌ها را با استفاده از پروتکل HTTP، انتقال می‌دهند.

توسعه‌دهندگان می‌توانند از این APIها، به منظور توسعه کارکردهای اپلیکیشن‌ها و وب‌سایت‌های خود استفاده نمایند. برای مثال، Pinterest API، ابزاری را برای اضافه کردن داده‌های موجود در صفحه Pinterest کاربران به یک وب‌سایت، ارائه می‌دهد.

بر اساس پروتکل ها / معماری

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

Remote Procedure Call (RPC)

ای پی آی های تحت وب ممکن است مبتنی بر اصول تبادل منابع برای اساس RPC باشند. این پروتکل، تعامل میان اپلیکیشن‌های کلاینت/سرور را تعریف می‌کند. یک برنامه (کلاینت)، داده یا عملیاتی را از برنامه دیگر (سرور) که در رایانه دیگر در شبکه قرار دارد، درخواست می‌کند و سرور، پاسخ مرتبط با آن درخواست را برمی‌گرداند.

پروتکل RPC، به عنوان فراخوانی یک ساب‌روتین یا تابع نیز شناخته می‌شود. یکی از دو روش پیاده‌سازی RPC، SOAP است.

• Service Object Access Protocol (SOAP)

روش SOAP، بر اساس تعریف که مایکروسافت (توسعه‌دهنده اصلی آن) ارائه نموده است؛ پروتکل سبکی (Lightweight Protocol) برای تبادل داده‌های ساختاریافته در محیط غیرمتمرکز و پراکنده است. به طور کل، این پروتکل، شامل قوانین دستوری (Syntax Rules) برای پیام‌های درخواست و پاسخ ارسال به وسیله دو اپلیکیشن تحت وب است. APIهایی که از قوانین SOAP پیروی می‌کنند، پیام‌رسانی XML را میان سیستم‌ها از طریق HTTP یا SMTP امکان‌پذیر می‌نمایند.

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

روش SOAP، عمدتاً برای نرم‌افزارهای تحت وب شرکت‌های بزرگ، به منظور تضمین امنیت بالای داده‌های انتقال‌ یافته استفاده می‌شود. APIهای SOAP، برای ارائه‌دهندگان خدمات درگاه پرداخت، مدیریت هویت، راهکار های مدیریت ارتباط با مشتریان و خدمات مالی و ارتباطی مطلوب است.

Representational State Transfer (REST)

واژه REST، توسط یکی از دانشمندان حوزه رایانه با نام روی فیلدینگ (Roy Fielding) در سال 2000، معرفی شد. بر خلاف SOAP که یک پروتکل است، REST یک سبک معماری نرم‌افزار برای ساخت اپلیکیشن‌هایی است که بر پایه HTTP (معمولاً وب‌سرویس‌ها) کار می‌کنند.

پروتکل REST، گزینه آسان‌تری نسبت به SOAP در نظر گرفته می‌شود؛ زیرا SOAP به نظر بسیاری از برنامه نویسان، نیازمند نوشتن کدهای بسیاری برای تکمیل یک وظیفه و پیروی از ساختار XML، برای هر پیام ارسالی است. REST، از منطق دیگری پیروی می‌کند، زیرا داده‌هایی را به عنوان منابع، دردسترس قرار می‌دهد. هر منبع به وسیله یکURLمنحصربه‌فرد نمایش داده می‌شود و می‌توان با ارائه URL آن، دسترسی به آن منبع را درخواست داد.

به APIهای تحت وبی که از محدودیت‌های ساختار REST، پیروی می‌کنند؛ RESTful APIs اطلاق می‌شود. این APIها از درخواست‌های HTTP استفاده می‌کنند: GET، PUT، HEAD، POST، PATCH، CONNECT، TRACE، OPTIONS و DELETE.

ای پی آی RESTful ، پیام‌رسانی را با فرمت‌های متفاوتی، مانند متن ساده، HTML، YAML، XML و JSON پشتیبانی می‌کند؛ در حالی که SOAP، فقط XML را پشتیبانی می‌کند. توانایی پشتیبانی از فرمت‌های متنوع برای ذخیره و انتقال داده‌ها، یکی از دلایلی است که REST، در این روزها، گزینه محبوب‌تر و متداول‌تری برای ساخت APIهای عمومی است.

3- چرا باید از API استفاده کنید

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

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

4- امنیت بالای APIها

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

• 5- معماری API

ای پی آی ها از سه قسمت تشکیل شده‌اند:

• کاربر: شخصی که درخواست می‌کند
• کلاینت: رایانه‌ای که درخواست را به سرور ارسال می‌کند
• سرور: رایانه‌ای که به درخواست پاسخ می‌دهد

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

6- نحوه کارکرد APIها

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

7- چگونه می توان از API استفاده کرد؟

1. یک API Key دریافت کنید

2. ای پی آی های endpoint را تست کنید

3. اولین اپلیکیشن خود را ایجاد کنید

اکنون می توانیم همه آنچه را که با هم آموخته‌ایم جمع‌بندی نموده و یک راهنمای گام به گام در مورد نحوه استفاده از API ایجاد کنیم.

7-1- یک API Key دریافت کنید

API Key رشته منحصربه‌فردی از حروف و اعداد است. شما باید یک کلید API به هر درخواست اضافه کنید تا API بتواند شما را شناسایی کند. برای دریافت کلید API، باید در سرور API ثبت‌نام کرده و اطلاعات هویتی خود را وارد کنید. برای مثال در RapidAPI – می‌توانید روش ثبت نامی را که برای شما مناسب باشد انتخاب کنید. روش ثبت‌نام می‌تواند شامل یک نام کاربری، ایمیل، رمز عبور، حساب Google ، Facebook یا Github باشد.

7-2- ای پی آی endpoint را تست کنید

پس از دریافت کلید API، می‌توانیم به API endpoint مراجعه کنیم (طبق قوانین موجود در اسناد) تا بررسی کنیم که آیا همه کارها مطابق انتظار ما انجام می‌شوند یا خیر. برای این کار، ما می‌توانیم از یک کلاینت REST، مانند Postman استفاده کنیم. در مورد RapidAPI ، این کار بسیار ساده‌تر است. بلافاصله پس از ثبت‌نام در سرویس RapidAPI، می‌توانیم به بخش API مورد علاقه خود برویم، در صورت لزوم در آن ثبت‌نام نماییم و سپس داده‌های لازم را مستقیماً در صفحه API وارد کرده و پاسخ endpoint را مشاهده کنیم.

7-3- اولین اپلیکیشن خود را ایجاد کنید

پس از بررسی endpoint و مطمئن شدن از اینکه همه چیز مطابق انتظار ما کار می‌کند، می‌توانیم شروع به ایجاد اپلیکیشن خود نموده و APIها را فراخوانی نماییم.

8- اقداماتی که می‌توانید از طریق یک API انجام دهید

می‌توان گفت یک API زبان مکالمه دو کامپیوتر با یکدیگر است. سرور، داده‌ها را در اختیار دارد و زبان را تنظیم می‌کند، در حالی که کلاینت از این زبان برای درخواست اطلاعات از سرور استفاده می‌نماید. APIها می‌توانند هر کاری را انجام دهند!

زبان و قواعد نحوی APIها، توانایی آن‌ها را محدود می‌سازد. در نتیجه، یک API به طور کل می‌تواند چهار اقدام را انجام دهد:

• GET:

در این حالت، کلاینت داده‌ها را از سرور درخواست می‌کند – این داده‌ها ممکن است، Status و یا یک داده خاص، مانند نام خانوادگی، باشد.

• POST:

در این حالت، تغییرات توسط کلاینت در سرور ایجاد می‌شود. به این معنی که اطلاعاتی به سرور اضافه می‌گردد: مانند یک ورودی اطلاعات جدید

• PUT:

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

• DELETE:

در این حالت، اطلاعات موجود در پایگاه داده حذف می‌شوند.

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

با توجه به صحبت درباره زبان و قواعد نحوی، بهتر است تا درباره نحوه ارائه درخواست به یک سرور نیز صحبت شود. برای انجام این کار، حداقل دو روش متداول زیر وجود دارد:

HTTP:

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

قالب‌های متنی: XML ، JSON. این زبان‌ها، زبان‌های اصلی دسترسی به داده‌ها از طریق API هستند. زمانی که داده‌های خود را دریافت می‌کنید، باید کدهای XML یا JSON را مرور نمایید تا بفهمید سرور چه اطلاعاتی به شما داده است.

9- Open API

بررسی و تحلیل خدمات سرویس‌گیرندگان مبتنی بر API در ایران نشان می‌دهد که صنعت بانکی یکی از بخش‌هایی است که در کنار صنعت تلکام و حوزه گردشگری بیشترین تقاضا را برای دریافت API داشته است.

ای پی آی باز معرف وضعیتی است که در آن یک سرویس‌دهنده بر اساس یکسری توافقنامه استاندارد و طی یک تکنولوژی،شرایط لازم برای دسترسی به خدمات خود را با استفاده از APIها برای توسعه‌دهندگان بیرون از سازمان (External Developers) فراهم می‌کند. حال اگر یک کسب‌وکار مدل پلتفرمی در این حوزه ورود پیدا کند و بر اساس تعریف و ماهیت یک پلتفرم، نقش تسهیل‌گری و انطباق را در کنار نقش حاکمیت (Governance) به درستی ایفا کند، ارزش‌های پیشنهادی (Value Proposition) ارزندهای برای بازیگران پلتفرم خلق خواهد نمود. از جمله ارزش‌های پیشنهادی برای سرویس‌دهندگان میتوان به کاهش هزینه، کسب درآمد مبتنی بر API (همانند آنچه در اقتصاد مبتنی بر API مطرح گردید)، افزایش تجربه کاربری مشتریان و بهره‌گیری از نوآوری ایجاد شده توسط توسعه‌دهندگان بیرونی اشاره کرد. همچنین در سمت سرویس‌گیرندگان که از آن تحت عنوان نهادهای ثالث یاد می‌شود، ارزشهای پیشنهادی نظیر سهولت دسترسی به APIها، تعریف محصول یا خدمت جدید، کاهش مدت زمان ورود به بازار و جریانهای درآمدی جدید قابل ارایه هستند. در تمامی موارد اشاره شده، API یک ابزار جهت دسترسی به یک خدمت از سرویس‌دهنده است که این خدمت با سهولت و سرعت بیشتری در اختیار کاربر نهایی قرار می‌گیرد. فراخوانی این خدمات توسط نهادهای ثالث از یک پلتفرم میتواند دریافت یک سرویس اتمیک باشد یا دریافت خدمتی باشد که از ترکیب چند API حاصل می‌شود.

10-  بانکداری باز (Open Banking)

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

خدمات مالی نوین: ایجاد یک راه‌حل جدید توام با امنیت کامل برای مشتریان بانک جهت کنترل داده‌های مالی
انطباق‌پذیری با تکنولوژی: مجموعه‌ای از تکنولوژی‌ها و استانداردهای داده که قابل استفاده توسط توسعه‌دهندگان بیرونی است.

خدمات مبتنی بر حساب: راه جدید و امن برای مشتریان بانک‌ها جهت انجام خدمات پرداخت مبتنی بر حساب بانکی
نوآوری: ایجاد نوآوری با بهره‌گیری از تکنولوی و مدل‌های کسب‌وکار جدید توسط نهادهای ثالث

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

11- فرایند باز (Open Process) 

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

زمانی که صحبت از Open Process می‌شود میخواهیم فرآیندهایی را مورد هدف قرار دهیم که قبلا داخل بانک یا سازمان نیاز آن احساس شده و به صورت درون‌سازمانی یا برون‌سپاری با بهره‌گیری از سامانه‌های داخلی پیاده‌سازی شده است. در رابطه با بانک‌ها، در صورتی که Core Banking بانک توسط یک TSP فراهم شده و جهت بهره‌برداری در اختیار بانک قرار گرفته باشد، ممکن است این TSPها باشد که فرآیندهای مد نظر بانک را بر اساس طرح واحدهای فناوری اطلاعات یا واحدهای مرتبط با توسعه کسب‌وکار، پیاده‌سازی و توسعه داده باشند. بنابراین بحث پیرامون فرآیند باز مسال‌های کاملا جدا از APIهای اتمیک یا ترکیبی (Composite) است. اما وجه مشترک آن حرکت به سمت و سویی است که این فرآیندها به جای اینکه در انحصار بانک یا یک سازمان باشد، روی بستر یک پلتفرم ارایه شود و میزان مشارکت و تعامل (Engagement) کاربران نهایی در آن افزایش یابد.

12- چرایی و ضرورت فرایند باز

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

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