Workflow Sample: October 2017

Operation: Reporting and reimbursement of expense

So-called "cloud expense management" is easy for system introduction.

Since it is a system specialized in management of expenses (out-of-pocket expense), both the reporting screen and the management screen are oriented to expense management from the beginning. There is no need to deeply worry about initial setting.

On the other hand, systematization of "expense management" is possible even in "cloud based Workflow".

However, since the workflow system is a general-purpose system, it is unexpectedly cumbersome to think up about items to be reported and to consider procedures such as supervisor approval, ledger entry, and reimbursement remittance...

However, from the viewpoint of employees who actually make report, there is no difference between "Expense management system" and "Cloud Workflow system". Eventually, the answer for "Specialized system vs general purpose system, which one is better?", is simply up to "organizational policy". Ah, it reminds me a controversy about "word-processor vs. personal computer" raised at the end of the 20th century.

Challenge: Delay in submission

However, the problem is that the accounting department gets angry that "There is no application for expenses!"

For example, a person in charge of preparing for an exhibition does his best until taking an approval in "flow of decision-making" (preliminary application). But when the the exhibition ends, he is not good at "reporting for expenses" concerning the contents of expenditure.

If a reporting task of "Exhibition at CERTAIN Exhibition" were already listed up on the "My Tasks" screen of the person in charge...

If it had already been automatically entered "ID of the approval document" or "Summary of the approval document" on the expense report screen...

[Expense Report flow]

Operation: Reception of "Information request"

Number of received information requests
Number of submitted estimates
Number of concluded contracts

Although it is a classic marketing method, "1) Number of received information requests" is an index that directly linked to "3) Number of concluded contracts". The correlation is extremely strong. Therefore, many companies set it up as KPI. Car dealer, insurance company, moving company, design office, and so on. It does not matter whether the scale is big or small or which type of business it is.

In the meantime, in order to realize a smooth Workflow, there are some companies that accept requests from customers at the "Form Start Event" of cloud based Workflow. By using a Workflow, downstream Steps such as "Address printing" and "Shipping" are also executed without mistake.

And the automatic transmission of the "Acceptance email" (placing an email transmission event) would be also "royal road". The customer can recognize that "the request was accepted". In addition, "Acceptance number" should be described in the text body. Doing so, the customer can make inquiry for questions through the phone or chat by tracking the "Acceptance number".

Challenge: Identity confirmation with Acceptance number only

"Process serial number" (# {processInstanceSequenceNumber}) is convenient for "Acceptance number". After all, KPI management is easy with it.

But at the same time, it is also a "number easy to infer". For example, when "cancellation of application" came by telephone or chat, it may be a situation inevitable to confirm "identity verification". In other words, if you are asked to cancel acceptance number 123 in a sincere voice, you may accept it as it is. But when you face a person who is likely to be malicious, you will confirm the identity by asking "email address". This could be called customer discrimination.

However, if it is a long number like a cipher text to be a "hard to infer number", it will be inconvenient. Not only "KPI management" becomes troublesome, but also it is hard to verbally tell on the phone, and it is rather difficult to guarantee that it is unique. Hmm...

[Information Request Correspondence]

Operation: A Large Amount of the End of the Month Billing

The monthly billing business at the end of the month has become to be conducted without missing!

With regard to "charged amount" to each customer, it became possible to catch in real time that who has input or who approved and when. Moreover, thanks to the "Automatic Step" which accesses the credit company API (Stripe API), charging to credit cards are directly performed from the Workflow system. In other words, it eliminates "dual entry" into the accounting system.

Challenge: Reduce Dependence on Human

However, this Business Process is still depending on "data input by human". That is, a human (sales representative) is in charge of input of "billing amount" that is crucial.

Certainly, "customer information" is set automatically, and "card billing code" (Stripe CustomerID) is also preset. Furthermore, "list of billing work" also appears on the list of Offered without missing, so it is easy to do the billing work by multiple people cooperating. So, I think that "labor saving of inputting" has been realized at a fairly high level, but...

However, the information on "charge amount" (billing amount) is in the "Sales management system" which is an "external system" from the viewpoint of the Workflow system. I wonder if there is a measure to automatically acquire sales summary somehow? (Today, "API economy" is urged out, and I think that where Business Process Improvement is heading to is "unmanned"...)

[Credit Card Charging - Recursive call-Full automation]

Operation: Monthly Credit Card Charging

Great labor-saving has done on the billing operation at the end of the month!

In the new Workflow application, "credit card charging" is automatically carried out as the department manager approves "Billing amount of this month" registered by the sales representative. There is no necessary for the Accounting side to do work such as "printing / signing / mailing of invoices". Of course, you don't need the work of "bank payment confirmation", either. Stripe, bravo! API economy, bravo! Questetra, bravo!

Incidentally, it gains favorable reputation also among customers.

They say it is good with that the expense details can be confirmed in "notification email", not to mention that the actual work such as "approval on invoice" and "procedure of bank transfer" has gone away. (Paperless)

(I wish "bank APIs" to be opened soon, as well...)

Challenge: Who is not charged?

However, it is hard to confirm "if I charged all the customers or not" at present condition.

Certainly, it is simply to Start (reuse start) the Workflow manually from "1r". However, relying on "manual" for its start, it would be hard to realize, for example, "to charge all the customers who billed in the previous month without oversight".

When the number of billing increases, "billing mistake" may incur, one day...

[Credit Card Charging - Recursive call]

Operation: Charging to Registered Card

I did create a mechanism of "Credit card registration"! (See previous post)

The mechanism is, credit card information such as "card number" and "CVC" is committed to Stripe (Payment Service Provider), and only "Stripe Token" (tok_ {24 characters}) as "deposit number", flows to Workflow. That means, it complies with what Japanese government is advocating that "Achievement of non-possession of credit card info by March 2018". (Non-possessing = The primal measure for protecting credit card information)

This will bring down "the risk of credit card info breaching from in-house system" to zero! Customers can make web registration without worry!!

* Stripe Token is a specification that can only be used for one processing (single-use token). In this example automatic conversion from "Stripe Token" to "Stripe CustomerID" (cus_ {14 characters}) is also done simultaneously. (Auto-step "Token to Cus_ID")

Challenge: Eliminate Manual-work in Charging Operation

But wait and look. What I did is just realized only "protection of credit card info".

Mistakes in "Total amount", for example, or in "Charge"... Risks of occurring such error in "charging operations" is not yet zero. Suppose if you had sent a charging statement to "email address of Mr. Brown" with "addressee name of Mr. White"...doesn't it make you shill?

Customer's name
Customer's email address
Token or Customer ID

Data like as above should be automatically entered beforehand. By making so, error rate will be close to zero. The burden on "unreliable boss" who is in charge of checking at the downstream Step will be alleviated a little.

[Credit Card Charging]