Have finally enlisted as an SDN blogger.
SDN : http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/u/251691744
Let's see how this is going to pan out.
Will still keep the wilbertSAPConsultant.blogspot.com .
I've come to like the link.
And there's bound to be things which is inappropriate for an SDN post... that's likely to come out here.
Tuesday, August 09, 2011
Sunday, February 20, 2011
Challenges of Growth
There exists a philosphical discussion on why firms exist. One viewpoint is that Firms are better information processors than the market. This means that the activities conducted within the boundaries of the firm are done more efficiently than if those activities are outsourced.
That viewpoint raises a challenge in a firm with distinct fragmented activities.
Why be a single company? If there are no advantages to being a single entity, why be?
This is quite a relevant question at that stage of growth when the company has acquired several firms or capabilities that seemingly complement each other at face value. In most cases, if left alone, these companies will implement tools to support their current activities. Maybe they'll cross-pollinate and take advantage of isolated capabilities as sales channel, IT delivery, suppliers but rarely do they consider global efficiencies. They still effectively run as individual businesses.
That means strategic positioning at the corporate level is quite difficult without a common vision. One of the catalysts of a common vision is a common IT platform. Having a single platform allows the transferability of skills and common understanding of information. It makes using information to support strategic decisions easier as data coming from the same system is likely to have similar meaning.
One other common issue with companies at this stage is that the supply chain is quite disparate. A single stream of product can have different warehouses, trucks, supply agents, distributors due to business units and geographies. Imagine a make-to-stock scenario across that chain and the buffer stock that you'd have to keep at each business unit.
There is an industry wisdom a few years old now : the competition is no longer about company vs company, but supply chain vs supply chain.
In another company's supply chain, similar products have the same distribution channel. They have a national DC and a single stage distribution to their major customers(e.g. Manufacturing site --> shared NDC with their customer --> Coles/Woolies site ). They are likely to have information agreements about stock with their major customers.
Just the comparison of inventory costs alone is sufficient to make a CEO stop and trigger a reorganization. I can only imagine that the cost structures of the two organizations is markedly different and that the second organization can be in a far better position even though if you take a look at individual business units, they're probably operating at the same manufacturing efficiency.
I can understand why companies and business units would want to protect how they currently do business. What they're doing brought them competitiveness up to this point and it's hard to argue why change a 'proven thing'. But those same competitive capabilities might be today's straightjackets and the agenda of individual fiefdoms can limit the the company's potential.
The fragmented company can find it harder to compete. Moving to a common business platform has its own pitfalls, but the vision is quite compelling. It's like playing footie. Individual stardom can only do so much against coordinated teamwork.
That viewpoint raises a challenge in a firm with distinct fragmented activities.
Why be a single company? If there are no advantages to being a single entity, why be?
This is quite a relevant question at that stage of growth when the company has acquired several firms or capabilities that seemingly complement each other at face value. In most cases, if left alone, these companies will implement tools to support their current activities. Maybe they'll cross-pollinate and take advantage of isolated capabilities as sales channel, IT delivery, suppliers but rarely do they consider global efficiencies. They still effectively run as individual businesses.
That means strategic positioning at the corporate level is quite difficult without a common vision. One of the catalysts of a common vision is a common IT platform. Having a single platform allows the transferability of skills and common understanding of information. It makes using information to support strategic decisions easier as data coming from the same system is likely to have similar meaning.
One other common issue with companies at this stage is that the supply chain is quite disparate. A single stream of product can have different warehouses, trucks, supply agents, distributors due to business units and geographies. Imagine a make-to-stock scenario across that chain and the buffer stock that you'd have to keep at each business unit.
There is an industry wisdom a few years old now : the competition is no longer about company vs company, but supply chain vs supply chain.
In another company's supply chain, similar products have the same distribution channel. They have a national DC and a single stage distribution to their major customers(e.g. Manufacturing site --> shared NDC with their customer --> Coles/Woolies site ). They are likely to have information agreements about stock with their major customers.
Just the comparison of inventory costs alone is sufficient to make a CEO stop and trigger a reorganization. I can only imagine that the cost structures of the two organizations is markedly different and that the second organization can be in a far better position even though if you take a look at individual business units, they're probably operating at the same manufacturing efficiency.
I can understand why companies and business units would want to protect how they currently do business. What they're doing brought them competitiveness up to this point and it's hard to argue why change a 'proven thing'. But those same competitive capabilities might be today's straightjackets and the agenda of individual fiefdoms can limit the the company's potential.
The fragmented company can find it harder to compete. Moving to a common business platform has its own pitfalls, but the vision is quite compelling. It's like playing footie. Individual stardom can only do so much against coordinated teamwork.
Tuesday, August 03, 2010
Ouch! Retrofitting a Partial OO program
I've just finished re-coding a partial-oo program. And it has been a taxing time.
The program uses classes but all methods were public and variables were global. It uses objects for the UI components (CL_GUI_ALV_GRID) and uses one massive class for data build full of public methods.
There was sufficient value in the UI components and data build. I really did not want to reinvent the wheel so I left it. It's the record processing components that we wanted to update. There was an issue because it was tightly integrated with the data build.
Good thing the data build logic is fairly simple.
Once I've taken out the old record processing components, I put breakpoints where update method calls need to happen. I tested that the program calls are is still consistent.
The data build contained business rule validations that needed to remain.The mechanical process of building a persistent class for update purposes was pretty easy. But the use of a new update object also need to ensure validations still work. The data which are now encapsulated in persistent objects were also used in the validations so they have to be re-thought.
I really should have known but what was experienced painfully first hand is that retrofitting partial oo programs is hard work. What I believed to be easy turned out to be massive because pre-existing logic have to be revisited every step of the way. An effective regression test of the whole program had to happen.
The program uses classes but all methods were public and variables were global. It uses objects for the UI components (CL_GUI_ALV_GRID) and uses one massive class for data build full of public methods.
There was sufficient value in the UI components and data build. I really did not want to reinvent the wheel so I left it. It's the record processing components that we wanted to update. There was an issue because it was tightly integrated with the data build.
Good thing the data build logic is fairly simple.
Once I've taken out the old record processing components, I put breakpoints where update method calls need to happen. I tested that the program calls are is still consistent.
The data build contained business rule validations that needed to remain.The mechanical process of building a persistent class for update purposes was pretty easy. But the use of a new update object also need to ensure validations still work. The data which are now encapsulated in persistent objects were also used in the validations so they have to be re-thought.
I really should have known but what was experienced painfully first hand is that retrofitting partial oo programs is hard work. What I believed to be easy turned out to be massive because pre-existing logic have to be revisited every step of the way. An effective regression test of the whole program had to happen.
Subscribe to:
Posts (Atom)