Workflow Sample: Stock Management

Showing posts with label Stock Management. Show all posts

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]

Who is holding it?

Laser pointers, portable battery chargers, portable projectors...
Corporate credit card, airline mileage card, PC software license...

Equipments in a company would like to be actively "utilized". However, "management" on these items is very troublesome. It will become a mere facade sooner or later if it is by the management method, for example, "record in Excel or Spreadsheet".

Cumbersome to update.
Don't know who should update.
Don't know when it was updated last time.
First of all, don't know where the management file is.
Oh no, there are lots of management files...

Hopeless, if it is a premise of"Long-term lending". As a result, even the essential matters, such as who is holding it, or is he or she really holding cannot be managed.

Firstly "loose management"

The following Workflow definition is a mechanism to record lending and return of goods. It can be said to be a system that records "inventory" such as "offered" and "returned".

As you can see from the Workflow diagram, I haven't done anything complicated. It is only a mechanism that the user of goods entries about "goods wanting long-term lending", and the goods manager (teller) records about "contents lent out". In this example, it is unique that the lend period is managed in year, month (e.g. 2017-02) rather than the date (e.g. 2017-02-13). It seems like suggesting "application for short-term lending is unnecessary".

[Lending Management]

Start workflow by external trigger

In the previous article "Episode 516: Method of Starting Workflow by "Email", I wrote about Workflow triggered by" Incoming mail ". Surely, I will be asked the question that "Is there any other way to start Workflow besides email?" (I have not been asked it yet, though...)

Yes, there are!

In the case of the Cloud based Workflow "Questetra BPM Suite", the APIs are provided as follows. "B1. Start Process" among them corresponds to all of HTTP / WebForm / Email. That is, it is possible to design a Workflow triggered not only by "Incoming mail" but also by "Web form input" or "Reception of HTTP request".

A. "Developer APIs" which Workflow system always provides (OAuth 2 / Basic)

A1. Operation by User (Workflow APIs)
A2. Operation by System administrator (System Setting APIs)

B. "Process Model connection API" which each business application provides

B1. Process start (Message Start Event) (HTTP / WebForm / Email)
B2. Standby in the middle of Process (Catching Message Intermediate Event) (HTTP)
B3. External transmission (Throwing Message Intermediate Event / Auto-step) (HTTP / Email)

Workflow to start Workflow

Even though it becomes a little "beyond the basics"... Since it has a function of "B3. External calling in the middle of Process", If you set it as follows

X-Process as to "transmit HTTP request", and
Y-Process as to be started by "Receiving of HTTP request",

so that connection between XY Workflows is also possible.

That is, you can realize the followings.

Well, now, In this article, I would like to think further about a method of"start multiple Issues at once" using CSV data.

[Batch starting of Telephone survey Process (Parent Process)]

[Telephone survey Process (Child Process)]

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)]

'Book purchase' on the company. It happens often.

Like Research institutes, R & D department, Marketing department... Books are indispensable for survey works.
Like Software company, Designing company, Construction company... Latest books are also indispensable for those creative businesses.

It's alright that 'someone buy books when he or she needs them', but information about those books which purchase on the company should be shared within the company. If there is an environment that anyone can see 'who and when bought which books' quickly, you may not have to buy books that you think you need. You may browse a book which you think not worth paying for at the office next door.

The following Workflow is a Book Purchasing Request. Not only for 'Purchase Request', you can use it for 'Report after the fact'. In other words, all the book purchase will be recorded, and that will become a Database of in-house library.

[Books Purchase Request flow]

Asset management is "troublesome". Especially, equipment management is "really troublesome". Equipment Management in administrative organs seems to be "Needless to say, troublesome".
Although, because it have been purchased with taxes, they never can say "supposed to be somewhere".

In Japan, they manage the equipment and consumables in accordance with the law, referred to as "State-Owned Articles Management Act". There, massive "document" to manage the articles occurs, but I want to migrate them to "digital document" in somehow.

The following Workflow defines a flow of operation called "Return". Procedures like a staff who was using a computer 'returns' the machine because no longer using it. (Articles Return Process)

My personal opinion, government is the one that should introduce a 'Cloud-based Workflow' initiatively, and promote Cloud industry, a new industry promising in the 21th century.

[Articles Return flow]