| Author | Message | ||
     Alfonso Galindo |
HI All, I have a question regarding elementary process and will appreciate any insights of the group. Given a change in the business process, now is possible for a user to automate several of his actual JDEdwards based processes. Starting with data from a franchise’s invoice (a) and complementary data (b) ( a & b will be the input side), the requirement is to automate the following processes: elaborate a Purchase Order (c), assign inventory (d) , elaborate a Sales Order (e), and finally elaborate and print an Invoice (f). In the actual JDE system, there exists a menu option (and functionality) to process each of the above processes, and it is expected the new functionality performs in the same way, updating all of the involved files and printing all of the involved reports, with just entering a & b data. The objective is to avoid the “manual” (c) to (f) process done step by step by the user in their actual system. Setting apart the justification of this kind of business process, the question is: How many transactional functions are there? Is there just one EI/EO (big one)? Or do we have several involved? How to identify them? (if we have more than one). Thanks in advance Alf | ||
| Steve Neuendorf |
Hello Alfonso, As a generalization, combining or separating steps does not change the elementary process. In fact, we could say that the whole emphasis on elementary process is to prevent over-counting by counting steps of a true EP as separate transactions. I have discussed this here before, but I use a principle I call "congruence". It says, that for maintaining data in an ILF, the add, change and delete transactions should be presumed to be congruent. Too often, someone will use the CPM examples to correctly combine the steps for the add (as in the employee - dependent examples) and will use simple logic to include all of the steps in the delete, but will then count employee change and dependent add, change and delete as separate EPs. In fact, the dependent activity is not self contained and all of the dependent maintenance is really a part of the EPs associated with employee. So even though I don't really understand your example clearly enough to answer it specifically, I would be inclined to say that those steps that are now done in the background should not have been counted separately in the manual form. I got my start in FP working office automation (who cared about productivity - having a computer and automation at any cost was more productive than not having one). We would function point count the business process, manual or automated, and then identify the processes that were automated or proposed to be automated and use that to determine percent automation and use that for planning and costing. Obviously that is an over simplification, where we also had to factor in capability and capacity considerations and partial automation, but the point is that the EP should be the same or nearly the same regardless of where you interject the UI. So say for example there is a process that passes the EP tests and has 5 sets of data needed to complete. It is still one EP whether I put all of the data in on one screen or on 5 separate screens or mix and match screens with feeds to include all of the data. Good luck, (and happy New Year) Steve | ||
| Alfonso Galindo |
Hi… Happy New Year for All Thank you Steve for your insights regarding this. At the same time let me try to clarify some of the facts of this case: The user already uses JDEdwards (ERP) functionality to process the described tasks, (elaborate a Purchase Order (c), assign inventory (d) , elaborate a Sales Order (e), and finally elaborate and print an Invoice (f)). These tasks (functionality) are accessed by the user one by one, via the JDE menu. The ERP changes Sales, Purchasing, Inventory and General Ledger registers (data sets), each time the proper menu option is used. Now, given a change in the business process, the user wants a new process which automates the described functionality from *c* thru * ef *. "In ONE step", with just entering two sets of available data (a & b). The solution that meets this requirement will be ¿One Big EI/EO? or ¿several ones? Thanks for your help Alf Note: Asterisk is used instead of parenthesis. | ||
| Steve Neuendorf |
Hello Alfonso, Your observation: "These tasks (functionality) are accessed by the user one by one, via the JDE menu. The ERP changes Sales, Purchasing, Inventory and General Ledger registers (data sets), each time the proper menu option is used." is not sufficient to make each of these steps an EP. If it were that simple, FP 1) would have been automated years ago, and 2) would have died shortly thereafter as soon as everyone recognized it was no more closely correlated to the dependent variables of interest (cost, quality, time) than any other physical measure or observation. The answer to your question is yes - there is one "big" EI and one EO after the automation. The "Ah Ha" is that (based on these facts) there should have been one big EI and one EO before the automation too. Remember there are 3 "tools" we use, none of which are how JDE or any developer (or even end user) decided to chunk up the UI: . . . meaningful; and self contained; and . . . consistent state. Practically, the analysis of these as separate EPs should have failed on "self contained" (that is what I look at first because it is the easiest). So, steps a-f are "self contained" and I could also go on to show how they meet the other tests. That only leaves looking at the primary intent, and there are two of interest: 1) maintaining data - acquiring enough data to produce an invoice; and 2) presenting data - producing the invoice. So, I "draw the line" to where steps a-e are the "big" EI and f is the EO. I would get the same result (though I might get different arguments) if this were counted as automated or before the automation. Good Luck, Steve | ||
| Alfonso Galindo |
Well, I understand what you mean, but if these were to be true and applicable to all situations, every single automation project would "reduce" the applications functionality and I'm not sure this would be the case; let me try to clarify it this way: 1) There are several elementary processes within an ERP System: Create Purchase Order, Item Receive; Sales Quote creation, Sales Order creation, and finally Invoicing. 2) Our user wishes to "automate" going through each of these steps, because they've created a "virtual" warehouse that doesn't actuall receive any items, they're just centralizing the re-invoicing from their franchise locations to the insurance companies for propper reimbursments. 3) In order to avoid going thru every step in the processes mentioned in (1) they wish us to create a new screen that allows them to input every piece of data so they can quickly jump these steps(executing each one) and go directly to invoice printing, thus avoiding manual work 4) These independent steps will not dissapear, because of audit reasons. The automation needs to - one by one - go through each step to leave the records and finish when the invoice is finally produced. Therefore, my question remains: Is this one SINGLE BIG EI/EO or is it several because of the distinct processes which it updates and the distinct business processes involved? Thanks | ||
| Steve Neuendorf |
Hello Alf, I am not so sure you are understanding what I said. If the application is counted correctly, then combining steps or adding new ones for an EP does not change the baseline. The only reason there was a change in the baseline count as you presented it, as a result of the automation was because of a correction to the counting the sub-steps as separate EPs. So if your steps in your point 1 are the same ones we have been talking about, each is not a separate EP. Don't take my word for it anyway; apply the tests. So, in general terms, there are two EPs that will pass all of the tests - collecting all of the data necessary to produce an invoice and producing an invoice. Even if you left in all of the original steps and added the new screen to duplicate it, the baseline does not change. It is as either in the hints about not counting alternate ways of doing the same thing or it would not pass the uniqueness tests if you get that far in the analysis. So the answer is still: is was and will be one "big" EI to capture the data and one EO to produce the invoice. Just to cloud the issue a little, it is an EI because the data has apparent use and meaning outside of just producing the invoice as you describe in the audit description. Otherwise, if the only user purpose of entering the data was to produce the invoice, it would be just an EO. Good luck, Steve |
