FDE Real-World Case: Automation Process Transformation of Fund Reports at a Hangzhou Manufacturing Enterprise

If you're a boss and want to use AI to replace the processes your company relies on people to grind through every day, this article walks through a complete FDE implementation case for your reference.

Hello everyone, I'm Zhihao. Recently I've been testing my FDE implementation automation recording process, and this article is one written by our zhihao-writing-agent, including the images, which it also created. So, let's begin reading this article.

A few months ago, I implemented a fund report automation process at a manufacturing company in Hangzhou.

Previously, the fund team had to rush out this report before 10 a.m. every day.

Now the report is automatically sent to the boss's email at 8 a.m. every day, and the fund team reviews it once a week. Before: every morning was like a battle

The company's fund department has 4 people managing more than 200 fund accounts across more than 60 banks.

Every day before 10 a.m., the boss's inbox had to receive a fund report for the entire group.

To produce this report, all 200-plus accounts had to be gone through one by one, transaction records downloaded from online banking, manually pasted into an Excel sheet with formulas, and then sent to the boss's email.

The fund team arrived at the office at 8:30 every morning and, like ants on a hot pan, clicked their mice to death rushing to send the report out before 10.

Below I'll explain in order which things I pushed forward for this process, from selection to launch. How to choose the first automation process

This process was proposed by the client's CFO. I judged it could be done first, and the boss gave the go-ahead.

I've always believed that the person closest to the business knows best which task drains people most every day.

The following three conditions are what I summarized afterward; you can use them directly when picking your first automation process:

Repeats every day. For something done every day, the difference becomes obvious quickly after automation.

Reported to the boss himself. The report goes directly to the boss's inbox every day, so the boss can see every day whether it's good, which gives him a reason to lead it personally.

Who decides what

In this matter, the boss leads, I'm responsible for pushing it forward, and the CFO and fund manager are responsible for implementation.

The process is defined by the fund manager.

My judgment is that the person who manages this matter knows best which step is prone to errors.

The acceptance criteria were proposed by me first, in one sentence: the results produced by the Agent must match the results done manually.

Then the boss and the team confirm together.

My view is that one sentence is enough for acceptance criteria: the boss can understand it, and the fund manager can execute it. Before and now: how each step changed

The new process defined by the fund manager has five steps: pull transaction records, reconcile, extract data, build the report, send.

I'll put before and now side by side, step by step.

Step one, pull transaction records.

Previously, a person went through more than 200 accounts one by one, downloading transaction records from online banking.

The remaining banks only allow logging into online banking with a USB key inserted; there are more than 30 USB keys in total, and RPA logs into online banking, inserts the USB keys, and downloads the transaction records.

These 30-plus USB keys are all plugged into a USB key enclosure.

A USB key enclosure is a box that can hold dozens to over a hundred USB keys; RPA switches which key to use via software, so no one has to stand by plugging and unplugging.

Step two, reconcile.

Previously, after transaction records were downloaded, they were manually pasted into an Excel sheet with formulas, and calculations relied on the formulas in the sheet.

Now the Agent processes all data in Python; the balance and transaction count of each account are automatically reconciled at the end of the transaction ledger, and then it verifies that the fund report matches the actual fund changes.

Step three, extract data.

The data is extracted from the Excel sheets exported from online banking, mainly the summary, counterparty account number, counterparty account name, debit amount, credit amount, and balance.

Each bank's format is different: some give only a change amount, using positive and negative signs instead of debit and credit; some write income and expenditure; and the column each item is in also differs.

Previously all of this was manually pasted into Excel.

Now Python reformats all banks' transaction records into the format required by the fund report, unified into counterparty account number, counterparty account name, debit amount, credit amount, and balance.

RPA is used first. When RPA fails, it's usually because the bank website page has been redesigned.

At that point it switches to the Agent, using computer-use to operate. After the Agent runs successfully, the Agent modifies the script.

If the Agent also fails, the fund manager is notified via Feishu to handle it. When the fund manager handles it, RPA recording is on, and a new script is produced.

If the Agent's reconciliation finds that the report doesn't match the actual fund changes, it goes directly to manual handling, also taken up by the fund manager.

My team's product staff produce a demo on site, and development takes it back for engineering:

On-site meetings, building the demo, passing business review: about 2 days;

Taking it back for engineering, including requirements confirmation, technical review, demo strengthening plan, development and testing: about 5 days;

Product testing and acceptance: 1 day.

9 days in total.

Unlike previous software development engineering, the demo must be produced on the business site: business people watch and evaluate on the spot, and only after review is passed does engineering begin; before engineering, business opinions have already been fully collected.

I'll write a separate article about this product R&D approach later.

At launch, there was no direct hard cutover; the new process ran in parallel with manual work for about 2 weeks.

After launch, the fund manager is responsible for maintenance. This is the division of labor I suggested; our team only ensures the Agent runs normally.

Now the treasury team no longer has to fight a battle every morning before 10 a.m.; they can work on requirements communication and improvements related to the treasury system. 6 things you can do in the first week

If you want to walk through this case yourself, you can start with these 6 things in the first week:

List the reports that land on your desk every day and every week, and mark which ones still rely on manual consolidation.

Ask the executive in charge which business process they most want to change first; the first automated process is best proposed by the business owner.

Screen it against the three conditions above: Is it repeated every day? Is there a manual result to compare against? Is it a report meant for you personally to read?

Break the process down step by step, and write clearly for each step who did it before, who will do it later, and at which step a person checks it. If bank statements need to be pulled, first classify the banks by data source: which have direct online banking connections, which go through a data management platform, and which can only use a USB token.

Work with the team to write one acceptance criterion, such as "matches the manual result." At launch, first run it in parallel with manual work for a period, and switch over only after they match.

Decide who will maintain it after launch, how often to review it, which metrics to look at during the review, and who to notify when automation fails. My suggestion is that business matters be handled by people in the business department, while the external team only ensures the system runs normally.

Once the first automated process runs successfully, you will have a visible sample, and subsequent processes can follow it.

Of course, you can also view our cases at fhxqtech.com.

Source: WeChat public account: Zhihao Plays What Today www.smartcity.team

Disclaimer: Please indicate when reprinting that the source is "Smart City Industry Analysis (www.smartcity.team)" and the relevant author. Except for original content, some information on this site comes from the Internet. If the relevant content involves infringement of rights, please contact the contact information at the bottom to delete it.

[Digital Technology Special Research] Community

In-depth peer exchange, focused on smart city and digital technology industry research and material accumulation.

Continuously updating the latest industry white papers, industry research, policy developments, and implementation solutions to help industry practitioners efficiently accumulate knowledge and share experience.

Massive amounts of essential content are continuously iterated, providing frontier perspectives, connecting industry talent, carrying out case co-creation and resource sharing, and jointly building a high-quality industry exchange atmosphere.

#post-##

Recommended for you

[FDE Practical Case] Beauty company implementation practice: using data cleaning to wash massive multimodal data into a set of trustworthy data

Ruipu Enterprise Introduction GPS Methodology: Why is your company introduction PPT full of content, yet clients cannot take it in?

Understand in one article: What are a database, data lake, data warehouse, lakehouse, and intelligent lakehouse?

[Architect's Ramblings] When we talk about business architecture, what are we talking about? — Looking at architecture from the perspectives of business, management, capability, and technology