Workflow Sample: April 2017

Season for reviewing Processes

April...

In Japan, it is a month when a new fiscal year starts.

Not only the accounting of the nation, accounting of local governments, new grades at school, etc. start, but also the ceremony for new entrants are conducted simultaneously in April. (About 20% of Japanese companies start their fiscal year in April)

It can be said that in Japan, April is 'the month when motivation for improving business processes increases' or 'perfect month for improving business process'.

Also in Questetra, Inc., which operates this blog, the amount of updating on Business Processes (number of version upgrades of Workflow Apps) will increase in April.

Dare to extend the time required

The business process introducing this time is a slightly strange improvement example that is "extending the time required at all Steps".

As a usual business improvement, it is normal to consider about improvement on "flows" or "data input screens" upon "dissatisfaction" and "challenges" that you are feeling during your daily work.

Automation of Steps
Addition of double-checking Step
Addition of guidance sentences
Implementation of handy button

And, in many cases, we will seek "a direction for a measure to shorten the total duration of work as much as possible".

However, in April, which is a break of the fiscal year, you might become wanting to deal with "inefficiencies you felt throughout the total counting work". In this business process (Workflow-App), it has been revised to stay in the middle of the way. (Addition of Human Process: "x. Retaining Rework")
Business process before improvement: Episode 511: Automatically Generate Transfer Slip File (Excel-CSV)

[Invoice Issuance-Retention]

Measurement of error rate

The invoice issuance process is one of the tasks in which mistakes are not allowed.

"Accounts receivable / sales" is recorded based on accurate billing data, and "savings accounts / accounts receivable" should be recorded upon collection afterword.

However, "redoing" occurs on the actual work site. For example, even in the same human process in Questetra, "Redo" occurred with a 2.8% chance as a result of last year.

Correction on "customer address and name"
Correction on "quantity and amount"
Correction on "issue date and due date"

Of course, the causes are various, including "unavoidable redoing".

Information was changed between order acceptance and billing (change of person in charge of customer)
The sales representative made a mistake in transcribing the contents of the order form
In the first place 'order data' was wrong

However, in any case, if the invoice (billing data) is "redoing the entire process again" when the customer receives it, in addition to the effort of redoing the bill approval processing, the data of the accounting system must also be manually corrected.

I must say such a "Redoing process from scratch" is "big loss".

Reworking and Sending back

In this business process improvement, the retaining Step of "x. Retain Sending back" of the Accounting manager is added, and progress toward the downstream process (data cooperation with the accounting system) is restrained.

That is, it will retain in the state that can be sent back to the most upstream, for a while (e.g. until the end of the month). (Reduce the risk of occurrence of "big loss" rather than increasing overall speed.)

Certainly, data such as 'sales' would like to be incorporated into the accounting system as soon as possible. I agree that it is a wonderful direction as a business management to further "accelerate monthly settlement of accounts" aiming for "daily settlement of accounts."

However, as in this example, "Business process that can absorb some extent of data modification by slowly flowing business Issues" can be another direction of business process improvement.

[Invoice Issuance-Retention:"1. Bill info entry" screen]

[Data Items list]

[Free Download]

Business Template: Invoice Issuance-Retention

Episode 488: Collaboration with Cloud Accounting (Part 3) (2016-06-20)
Episode 502: "Master Reference" is for Eliminating the Fluctuation! (2016-09-26)
Episode 479: Cautions for Letting "Prorating" to Script Step (2016-04-18)

<<Related Articles>>

[Japanese Entry (和文記事)]

Is information collection a "business"?

There seems to be various opinions. If you watching television programs in the conference room, it might be a "business".

And if you are working for a department store, you may care about news concerning "Department stores". Or if you work for an Internet company, you might be curious about keywords such as 'AI', 'IoT', and 'big-data'.

If "special program" related to those keywords is scheduled as a television broadcast, you can't miss it. Particularly if it is planned by public broadcasting station, the impact on society could be very big.

＜NHK API control screen＞

NHK API that opened to anyone

NHK, a public broadcasting station in Japan, has published "Program Guide API". In June 2016, they started provision of Ver.2 , and it is now possible to acquire program information of "7 days ahead".

Response excerpt

"id" : "2017041215654",
"event_id" : "15654",
"start_time" : "2017-04-12T04:30:00+09:00",
"end_time" : "2017-04-12T05:00:00+09:00",
"title" : "ＮＨＫニュース　おはよう日本",
"subtitle" : "▼国内外の最新ニュース　▼スポーツ情報　▼地域の課題や話題のリポート　▼日本と世界の気象情報",
"content" : "※番組内容は変更になる場合があります　▼番組ＨＰ　ｈｔｔｐ：／／ｗｗｗ．ｎｈｋ．ｏｒ．ｊｐ／ｏｈａｙｏｕ／",
"act" : "【キャスター】森田洋平，【気象キャスター】酒井千佳",

This API is a very simple OPEN API.

As long as you register yourself, anyone can access it immediately, and regarding usage rules, it is very clear that "up to 300 accesses a day".
There is no authorization flow such as OAuth1 / OAuth2, it is not even secure communication (HTTPS)!

On the other hand, it can be said that it is APIs strict to standard specifications.

That is, if you are using various APIs on a daily basis, you would suppose that the characters that can be used on the website (UTF - 8) are communicated as they are. However, it is "Truly NHK". They firmly comply to the rule which "Send and receive with only alphanumeric characters (ASCII characters)" (Unicode escape) (JSON RFC7159) , so each and every Japanese character is converted to \nXXXX. (Even though It is hard to use in verifying communication log etc.)

[Keyword Search on TV Listing]

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]

Isolation of Accounting Steps

It is very convenient if prepared "PayPal Billing Flow" as "Independent Subroutine Process".

Since it can be called from various business flows in the Workflow system, the process owner can focus on the design and maintenance of the main business flow.

Even from the perspective of the Accounting department on the downstream side, they will be able to perform efficient business since they can handle multiple business flows without distinction. (However, involvement to upstream will tend to decrease.) In addition, there is a need that "want to manage and maintain centrally" in the accounting system (*) in which the changes in the past one or two years were extremely vigorous.

* ※ "Cloud Accounting", "Bank API", "Accounting BPO", etc.

Processing of PayPal Invoice

The following business process definition (Workflow / App) is "PayPal billing process" which automatically collaborates with PayPal.

Various requests are made from the Workflow system side via "PayPal REST API", specifically "PayPal Invoicing API". That is, it is a mechanism that

let PayPal generate 'PayPal Invoice'
let PayPal send "PayPal Invoice"
check payment status of "PayPal Invoice" against PayPal.

(The opportunity to login directly to PayPal will be reduced.)

[PayPal-Invoice]

Subscribe to: Posts ( Atom )

Pages

Episode 532: Recording to External System, More Haste, Less Speed