Workflow Sample: Purchase

Showing posts with label Purchase. Show all posts

Continuing the past two weeks, I will introduce you the operation of "Starter Template" which has been pre-installed in the cloud-based Workflow, "Questetra BPM Suite".

The third one is "Out-of-pocket Expenses reimbursement claim".
Episode 464: Out-of-pocket Expenses Reimbursement Claim (Starter Template) (2016-01-04)

It is a business flow to make an application for claiming with email attachment of images of receipts taken with a mobile camera. And there is a focus on making it easier to manage receipt images by applying sequentially. Therefore, this will be a business process which is on the premise that "regulation that allows discarding the original paper receipt by taking a receipt image with a mobile camera".

[Out-of-pocket Expenses claim]

Continuing from the last week, I will introduce you the operation of "Starter Template" which has been pre-installed in the cloud-based Workflow, "Questetra BPM Suite".

The second one is "Procurement Request".
Episode 463: Procurement Request (Starter Template) (2015-12-28)

It is a business flow that allows anyone to make requests for purchasing from consumables to equipment as long as they are employees. Since status management such as "Decision pending " or "Delivery waiting" is automated, you can check progress at any time.

[Procurement Request flow]

Automatic operation of bank account

"Banking APIs" is booming in Japan.

Questetra Inc., which is hosting this Workflow Sample blog, can also check real-time deposit information by "the benefits of API cooperation between" MF Cloud "(Accounting Cloud) and" Mizuho Business Web "(Bank Online Service)" , And the record to the accounting system is to be processed about on the same day (daily settlement). (Information on accounts receivable and so on that can be created only by workflow is still by "CSV import" ... but I believe MF Cloud itself would provide an API in near future ...)

* Incidentally, cooperation by "scraping method" (method of passing bank password to the Accounting-cloud) has been forbidden to use.

The policy of "Bank API" that enables data connection of this deposit / withdrawal information is expected to be legislated as "revision of the Banking Act" in 2017, and the FinTech industry also accepts it favorably. Therefore, it is expected that the bank system and various online services will be closely connected in the future.

Start with data retrieving API

However, at present, only some businesses can access "Bank API".

For the future as well, it is expected that a certain review will be in place to become an accessible business operator. Moreover, it could be a "licensing system", depending on the discussion in the current Diet session.

Also, regarding the access permission of the bank side, there is a possibility that it will be limited to "Data retrieving API" for the time being.

That is, I suppose that it is started as a service limited to data reference communication without movement of assets such as "acquisition of deposit / withdrawal information" or "acquisition of balance information", as a trial operation period of "API service". (Even though cases of 'Data updating API comes out already since April 2017...)

By the way, "Issues unique to Japan" is also hidden.

That is, there are historical circumstances that most account names have been handled in "Half-width kana" which is uncommon for modern computers. It results that systems accessing to APIs will be required "Data conversion" for their own (Automatic Journal entry rule, etc.)

[Remittance Process]

I'm going to consider "Starter Template" of the 2016 edition.

This time, it is going to be the 3rd of the series, "Out-of-pocket Expenses Claim" in simplicity.

This Workflow will be Started by sending an email with attachment of receipt image taken with Smart phone. (Email Start)

Despite Reimbursement claim for Out-of-pocket Expense is carried out collectively at the end of months in most companies, in this example, it must be done at each time payment occurs. It is a focused to ease the management of the correspondence between the receipt image. After all, it is a business flow to let an employee to make E-mail application at the moment of getting a receipt, such as taxi fare or dining bill. It should be noted, it must be sent from a company email address (Login ID] of the workflow).

(That is not difficult for employees of a company that has introduced a Cloud-based email system like Google Apps.)

By the way, although it might needless to say again, this Workflow is a Business Process in anticipation of "Regulation change (around January 2017) that allowing to discard the original receipt replacing with the receipt image taken with smartphone".

Even though it seems "Premature" to include this into "Starter Template pack" of 2016 edition, yet it is significant to be ahead of the next generation toward the coming era of "Taking picture of Receipt with Smart phone". We should actively operate this Workflow in commissioning, and prepare by organizing various issues on its operation in advance. (Be aware that you are required to store the "original receipts" until the end of 2016. In addition, it is different from the regulation which has been enforced in October 2015, in the point of "Image of Scanned receipt".)

[Out-of-pocket Expenses Claim]

I'm going to consider "Starter Template" of the 2016 edition.

This time, it is going to be the 2nd of the series, "Procurement Request" in simplicity.

This procurement flow is a Workflow that allows you to comfortably make requests for anything you think you want to or should buy.

That is, it is possible to request for anything, as long as being an employee, from consumable goods such as "copy paper", "drinking water", or "detergent", to fixtures like "desk", "vacuum cleaner", or "personal computer". However, it is left to the Procurement Department for actually whether or not purchased. Especially, for those difficult to determine the need and urgency, it will be in a status of "pending the decision for purchase" for long term.

Incidentally, "being approved on the Approval flow" in advance will be the premise of purchasing of the "application for purchasing items of more than 100,000 JPY ".

[Procurement Request]

"Competitive quotes" are important.

"RFQ" should be created properly not only in listed companies, but also in every company. These will be notified to the suppliers, and then should be saved as important business records together with the subsequent business data ("quote from the suppliers" and "evaluation to each estimate", etc.).
(RFQ: Request for Quotation / Request for Price Quotation)

The following Business Processes is a Competitive Quotes flow for general purpose. (Procurement)

From "purchasing of raw materials" to "Planning of Company outing", it can be utilized for various RFQ. All the progress of procurement will be automatically recorded / visualized when you import this flow into your Workflow platform and run it as a business system.

1). RFQ will be sent automatically,
2). Received quotes will be attached,
3). Quote will be evaluated by two people,
4a). Notification to the winner will be transmitted automatically,
4b). Notification for the loser will be transmitted automatically.

Needless to say, there will be benefits in various aspects, such as business records, knowledge sharing and internal control.

Destinations of past RFQ will be be referable
Track records of answers from requestee (suppliers) will be referable
Track records of evaluation of requestee (suppliers) will be referable
Frauds and unsavory ties will be prevented

[Competitive Quotes flow]

I'm going to eliminate the waste in work!
I'm going to smoothen the transferring of data!

Thinking about projects such as 'Paperless' or 'Email replacement', the operation that hits my brain first and foremost is "Sales related operations".

Approval flow for "Estimate"
Sharing flow for "Orders Information"
Progress management for "Product Shipment"

Indeed, improvement of efficiency of those operations would directly lead to "Increase of Sales". Moreover, the improvement cycle would also be shortened because 'Issues' will be flowed almost every day.

However, for organizations that (a) experience of drawing Business flow diagram is poor and, (b) not got used to BPMS tool,,, there will be a high risk of being stuck up with such as;

Range of Business Process definition is too large
Business data items are too many
Configuration of Split condition is too fine
Lack of unification on Cautionary statements on Input form

when trying to use a "Business Process Management (BPM) tool" for (1) Defining business flows and, (2) transferring business data, actually.

It is one of the best moves that to specify the business, which is closed to internal company and with a smaller number of steps, as a pilot project, if you wanted to proceed your business process management activities (BPM activities) steadily. The following "Business Process definition" is a flow of "Expense Report (External Payment Request)", with fewer Steps. It is very significant in terms of internal control and mutual supervision, when you stop using e-mail and verbal to communicate, and let the issue data flowing through the Business Process Management system. In addition, the aggregate data will also be a very valuable business data.

[External Payment Request (except Payments made on behalf, Credit card settlement)]

'Daily Report', which is always indispensable for Sales section or Procurement section.
It is a framework that to summarize the day's results and impressions, and to be submitted to the manager every day. It is a very effective method to share information for certain type of business. It is convenient for who submits the report as well as who leaves comments because they can handle in the daily cycle.

However, in the other hand this Daily Report will not be read by other than the managers. Though it is the precious live information... Though it is the precious record... it is nothing but wasteful.

The following [Interview Report flow], an example of Reporting flow, the frequency of the report is assumed as 'whenever' instead of 'Daily'. So the title of the report will be "AAA.,Inc 20yy. mm, dd" instead of '20yy. mm. dd personnel name'.

By doing this, it will be easy to refer when you search for 'Name of Customer'. When you search for 'Name of Customer' over the whole Workflow system, not only history information stored in [Interview Report flow], you can browse history information also in [Order flow] or [Estimate flow].
It will allow an Accounting personnel to quickly reference contact record of the past when he or she had suspicion on the invoice from the outside. It will allow management to obtain information of time series such as from the initial contact, to Estimation work, Contract processing and to Billing.

[Interview Report flow]