Amanda's ERP Journal

[amanderpjournal-blog]

Seminar 4 Order-to-Cash

Sheet is getting serious because we have received email from James telling us to meet in FTR for lesson instead of the usual seminar room. One of our classmates, and my very talented ex-project mate, Jeremy, gave a presentation on the MIT conference he attended. Among the points he discussed he talked about the reality of 4D printing (the ability to allow objects to respond to time, for example rusty irons un-rusting themselves), driverless cars (which is something of interest to me because my group researched on this for one of our other projects) and hydroponics in buildings.

The main takeaway from his presentation was the realisation how fast technology is advancing. I mean, yeah we keep saying "rapidly advancing technology" but wow. It's advancing really fast. And the most impressive feat of all was that these are actually technological solutions created for very very valid problems in the world. It's not for some fancy thing like, game simulator (I mean that's pretty impressive and I'd pay an arm and leg for that but, it's not for a really practical cause) or I don't know, a handphone that brews coffee for you or something. They solve problems like rust, car accidents and congestion, limited agricultural space in urban cities. That is what is amazing. We speculating Earth is going to die in a few more m/billion years due to the problems faced by population growth and stuff. But wow. With the rate technology is advancing the problems may soon be a thing of the past. (Or present, since our present is the future's past.)

ANYWAY.

During lab, James posed us a problem. How are we to make the process of updating certain documentation regularly every period more efficient? That is, how are we to use the SAP system to update the documentation automatically?

There were a few solutions discovered by the class's insane googling skills, one of which includes recurring jobs and scheduling. This was also the day I realised SAP is like Batman; intimidating and difficult to approach at first but once you understand him he will be your greatest hero in your corporate life.

Sapman.

The lab also gave us a taste of what our projects will be like.

For the second-half of the seminar, Sherlock did Order-to-Cash and they provided a pretty good view of what the process essentially is.

This topic essentially boils down to one word: communication. But before I go into my insights lemme just briefly touch on what they did go through in content.

We learnt that in a company, there are many, many, many, many documents that needs to be filled and passed on to other departments. Playing the role of an extremely ancient company, all of the paperwork is done on, well, paper.

I didn't know what to expect.

This process just reeks of so much inefficiencies. To name a few,

Delay between passing of one form to another There is just so much time being wasted while waiting for one form after another to be filled, most of the times because the forms which we are in charge of filling can't be filled without information from another so we have to wait for them.

Error in copying  Copying = reproducing same set of data again and again on different forms. Gee, I wonder how can technology solve this problem?

And this is just a class scenario, where the size of the entire company, warehouse included, is the size of a seminar room.

Imagine this playing out in very real companies in the world. Oh the inefficiency! Each department has very different roles to play:

Sales 1. Seek out new customers 2. Provide quotation 3. Bargain Negotiate with customers 4. Provide sales order form and passing it to Warehouse 5. Credit checking with Finance Department

Warehouse 1. Shipping 2. Packing 3. Delivery 4. Inventory Checking 5. Receive sales order from Sales Department 6. Send delivery form to Finance Department

Finance 1. Credit control/check 2. A/R 3. Account-ish stuff 4. Receive delivery form from Warehouse

Almost every one of the points I mentioned (and I've omitted quite a lot) require one form/documentation to go with it. So imagine manual writing on so many documentation. And there is so much dependency between the forms. If one screws up along the way, everything screws up. That is how inefficient this process is without SAP.

That is why communication is important. Communication with other departments, within the departments... In a business process, communication comes in the form of documentation. If documentation is wrong, communication breaks down. And this is how SAP works as more than just a technical computer-ish kind of software. It acts as a medium of communication between parties. It provides the most accurate information and least amount of human error. Communication is only as strong as its weakest link; so long as there are no human errors when keying in fresh data, communication is strong. 

Communication

This, in sync with what we have learnt in lab (something along the lines of "Wow SAP can do pretty brilliant magic."), business processes have the capacity to be so much more efficient that it is now. Of course this leads to another problem when security/accessibility issues occur. But that is saved for another time.

[amanderpjournal-blog]

Seminar 3 (Business Process Redundancy, Accounting Process)

The seminar started off with a case study and identify the redundancies in the diagram as a recap. This session has not only reinforced what I learnt last week, but even added on to the value of which has been taught. These are the main points of discussion in class, what my personal, perhaps unorthodox, thoughts:

Having 2 systems that share related data is inefficient, and is more common in the real world than I thought Having experienced such inefficient processes where two different systems share similar data/functions in both my part time job as an assistant at a tuition center and for my group's client in Database Management, I truly have no idea why would a company would engage two systems, other than that they did not plan properly when hiring professionals to create the database for them. This brings to mind the absolute importance of overseeing your business process and optimizing the process as much as possible, so as to reduce costs (of creating database twice) and for maximum efficiency. However upon further discussion I may have thought of a few rather valid reasons why some companies do not have a centralized database: a.  Standard practice From a personal experience, when reviewing lectures, I would first write down notes on my printed notes, then type everything out onto a word document. I adopted this practice because I would consider the notes writing to be sort of a draft before typing it into the computer, it is much much faster to pick up a pen and paper and write than to open up your laptop, sign in, wait for Office to start etcetc. So in application to the working world, I would see why (mostly) staff would prefer collating the information on an excel/writing down on paper before transferring over to another system.  While we can't change habits or traditions, I think this is a harmless practice. The only time we should worry is when they decide that the draft version of their data is to be used in the system. A draft is extremely unorganized and adding it to an organized system can be a nightmare. Some men just want to watch the world burn b. Different systems for different intents and purposes When brainstorming on why companies might have adopted more than one database, I imagine the following scenario:

Management: We need to digitalize the WhatDoIEatForLunch Process for efficiency. Let's hire someone to do that.6 months later...Management: We need to digitalize the INeedToSlimDown process. Let's hire someone to do that.

Point is, I would imagine the management viewing one system for one function. While deciding what to eat for lunch and slimming has different intents (one is to fill one's stomach, another is to not fill one's stomach so much), they still share similarities that perhaps the management cannot see (one has to control one's diet to slim down). This is all the more reason we need ERP to centralize and provide an overview of the process to the management so they can see the bigger picture.

Receipts: physical or digital? The argument for physical receipts is that we need proof of the claim. Physical copies are much harder to forge. As IT people however, the class unanimously agreed that digitalizing things would make everything much simpler. The standard practice in the real world is to have both copies: we keep the physical copy in a folder for validation purposes, and a digital copy for data management. This sounds redundant, but this is the most practical practice we can take up now. Although I wish that sometime in the near future, business would give out more digital receipts with valid ways of proof, so that the office can be less cluttered with physical receipts and data flow is much more efficient.

While having a systematic structure to follow boosts efficiency in a business, we must not forget a little flexibility goes a long way Digitalized systems are systematic. Too systematic. I guess this can be called a case where something is too good for their own good. This makes the system extremely inflexible and lacking the human touch. This is why some presence of human judgement is still needed. It is a business; not a factory after all. Unless technology produces some form of superior AI right now, this is something technology cannot handle as yet. Future SAP problems: databases falling in love with each other

Things are getting digitalized at such a fast pace that we, as IT people, don't understand the resistance this rapid change is putting people in. This has been the recurring theme in my mind as we discussed in class. We keep talking about how integrating everything into one system is much simpler, how digitalizing receipts is more efficient, how data duplication is redundant and automating everything is the best. But we forgot that we are IT people; we understand and trust technology enough, but we didn't listen to actual people. I understand where people resistant to the changes are coming from: they have a deep mistrust of the system from the start, just bombarding them that it works well does not lessen their mistrust. Thus in the field of ERP, we act as the bridge between IT and people. We are communicators. We need to listen to both sides, see things from their perspective, and persuade them in a softer manner.

For the second half of the seminar we had a recap of the accounting process. This serves as good revision as I am finally starting to see how different modules relate to each other and starting to appreciate accounting. (I am a slow learner.) Aside from the basic terminologies and definitions (managerial/financial etc), there are so additional nuggets of information I have not realized in Year 1.

Accounts Receivable is much more complicated than just being an entry in a journal. We are dealing with people, after all. People are complicated. Love isn't. Thus there is a need for a Dispute Management department to work out the terms of unpaid payments and dealing out consequences to clients.

Accounting department in MNC is a huge business. It is also a huge headache. There are many problems MNCs can face: currency conversion problem, time differences problem, different accounting standards, different credit evaluation basis (for example a client in Brazil may understandably have a harder time repaying debt than a client in New York) etc. Some of the problems, while being a major inconvenience, is not a major dent to the MNC's efficiency so we just have to live with it. (We can't exactly force every single person on Earth to exchange in doge coins, or force half a sphere of population to reconsider night as 10am.) Some we get around it by setting standards, which although does not solve the problem, it does alleviate the problem to an extent. Wow much standardized so currency

SAP, however, can largely alleviate this problem too, but centralizing everything into a centralized database globally and take whatever we will of the information stated there. 

There are three kinds of lies. Lies, damned lies, and statistics. - Benjamin Disraeli

Seriously out of context, but the point of the quote in relation to this post is that SAP manages data. The problems faced by MNCs are not related to data, but interpretation of data. So while SAP can help organize the data, it has not developed psychic abilities to change people's interpretation of data, and interpretation is up to the business standards.

[amanderpjournal-blog]

Seminar 2 (Business Processes, Business Process Modelling)

We learnt about the overview of the business process in an organization. Having been someone who have absolutely zero prior experience in any form of business, here are some of my main takeaways, from a total beginner's point of view:

1. Business organizations, if GBI is of any indication of the standard business processes (and of which we learnt that there are no actual 'standard practises') have the very few essential functional groups: marketing, IT, finance, human resource (HR), R&D and operations. 

When it comes down to the very specific functions of an organization, sometimes the job scopes overlap and it makes sense to categorise it under either two or even three functional groups. It depends on the nature of the business or the preference of the managerial group.

For example, marketing usually takes care of both marketing and sales. On a side note, the difference between sales and presales is that presales is usually the department who are the experts on the product the company is selling. This is especially important for companies selling software. Companies would usually group service and support under the marketing department too, as with reference to the context of our IT course, it makes better marketing/sales sense for software to come with support as one package. This encourages customer loyalty, alongside partner enablement programs that some companies choose to adopt. Typically for companies like SAP, they can build an ecosystem around their product, making customers, suppliers and subcontracting firms alike stakeholders in their product and further adding value to all the stakeholders involved.

As another example, Operations has a huge undertaking. It is typically in charge of material planning. While closely related to manufacturing, sourcing for materials is procurement's job. Procurement may also be responsible for new offices and warehouses etc, and it is possible for procurement to be more administrative. However in the case of GBI, I would think that as a company which manufactures bicycles, admin matters are minimal and would belong to the operations side. Distribution department is in charge of managing the network of distribution: which includes shipping, warehouse locations, capabilities of warehouses and transportation. Planning warehouse is also not an easy feat: one would need to decide on which is the best location to store the finished goods so as to minimize transport cost (closely linked to distribution), storing raw materials (in the case of GBI, it makes sense that manufacturing and warehouse are in same compound).

For future references, with relation to the GBI document, the expansion of the functional groups as discussed in the class is as below:

VP Marketing: sales (Heidelberg & Dallas) , marketing (Heidelber & Dallas) Chief Info Officer: IT (Dallas) Chief Financial Officer: finance (Dallas) VP HR: HR Groups (Dallas and Heidelberg) VP research & development: Research and design (Heidelberg) VP Operations: procurement (Heidelberg and Dallas), manufacturing (Dallas and Heidelberg), warehousing/shipping (Heidelberg, Hamburg, Dallas, San Diego, Miami), material planning (Dallas)

2. Strategies are obviously very important. The strategy adopted is relevant to all parts of an organization so a lot of knowledge is crucial for successful strategy planning, but CEOs need to decide on a direction the company needs to take (vision, mission etc). 

Some of the strategies adopted by the various functional groups are discussed below:

HR: restructuring (taking concepts learnt from Organizational Behaviour), perhaps coming up with a pipeline for employee promotion Finance: how to find new funds, budgeting (note that it has been discussed too that budgeting may involve the various departments as well)

In short, the main point is that I've learnt to appreciate and understand the different parts of the enterprise and how they come together to, in Jame's words, "give the customer the sandwich he wants." 

In the student-led lesson, we discover even more in-depth details about the business processes. Essentially, I learnt that:

Business silo is inefficent

Business process is different from business function

The importance of smoothening an organization's business process is to provide an overview of the business functions and to eliminate redundancy

How to create Business Process Models Pools (departments) Swimlane (different actors) Boxes (processes) Diamonds (decisions) Terminators (start and end, may or may not have one end and where the End is is not exceptionally important) Page Connectors

BPM makes it much easier to notice redundancies

Redundancy/inefficiency is not implemented by the various departments on purpose, sometimes they do not even realise it themselves. Thus we need the BPM to allow a bigger, more comprehensive view.

This is the first seminar and it has been extremely informative so far, especially for an inexperienced student who just started dabbling in the world of business. The lack of final examinations made learning even more conducive, in my opinion, as it allows me to learn "indiscriminately" without having to take extra note of what will or will not come out in the exams. I am looking forward to the next few lessons!