|
Scheduling an Oracle project - Is full schedule really needed or we should use only "good-enough"? |
|
Jul 14, 2008 at 01:23 PM |
|
I faced two models in general: 1) Full scheduling (requirements--> PBS--> WBS --> schedule) as it is taught in ERP training.
2) Only generic name of basic tasks, responsible, deadline (Most top consulting companies use this pragmatic approach for their implementations, upgrades, etc…
I find that keeping the scheduling process as simple as possible works best.
People who do not fully understand PM terms can be intimidated by such terms and this can lead to difficulties.
In my view point, a fully detailed schedule for the entire project is usually pointless because the level of uncertainty is too high to be of any real use.
Best practice is to divide the project into stages (or phases.) and produce a detailed schedule for the current stage, with an outline schedule for the rest of the project. This gives you the detail and accuracy to effectively manage the tasks at hand, and also the long-range forecast for delivering the entire project.
One of the tasks in each stage is to produce the detailed plan for the next stage. This is the real pragmatic approach because you are only putting the effort into a detailed plan when you need to, and when the level of certainty is as good as it can be.
Personally, I use placeholder tasks early on the in project - e.g. having a Transition stage which contains various testing, training and deployment summary tasks. Each summary task has a subordinate task called "placeholder" which has an estimated duration. This ensures that anyone reading the plan is clear that the detailed planning has not yet been done for that stage, while still providing some indication of the likely duration.
Most new methodologies follow this approach (Agile, Accelerated, FastTrack, etc..)
These approaches advocates "phases" called "Releases", a 3 month period in my world that enables me to set a meeting schedule, deliver a fairly accurate list of things that will be completed within the Release and discuss "Team Capacity" of the individuals involved taking into account vacations, other commitments, etc |
|
|
The difference between MDM Systems and Data Warehouses |
|
Jul 06, 2008 at 10:10 PM |
|
In many ways, the processes are similar to those used in populating a data warehouse or datamart, particularly with the consolidation style of MDM; however, there are differences: Volume and Type of Data: MDM systems involve only the master data, not terabytes of transaction data (such as telecommunication companies' call detail records), which may need to be stored at the detail level, in addition to various levels of aggregation for analysis purposes. Database Design: The master data is typically held in a relatively normalized form, whereasmany analytical systems depend on specialized designs, such as star schemas to improve analytical performance. Use of the Data: MDM reconciles semantic differences to give a single view of master data,usually for operational purposes, which is independent of any single application system. Datawarehousing supports BI and analytics, but does not usually support transactional activities. MDM systems and data warehouses are complementary, and the introduction of MDM systems into the operational area should reduce the work required to integrate and consolidate master data as it's prepared for loading into the data warehouse. |
|
|
Jun 22, 2008 at 12:00 AM |
|
A great salesperson has the following 10 qualities:
1. Integrity & Character: 100% honest, always transparent and represented himself and the organization with great class.
2. Tenacity: relentless in his pursuit of success, never giving up or allowing a set back to cause him hesitation in driving the business forward.
3. Adaptable: always flexible and embraced change.
4. Innovative: continually thought outside of the box for new and better ways to do things.
5. Self Aware: learned from his mistakes and built his confidence through his successes.
6. TEAM Player: subscribes to the "Together Everyone Achieves More" philosophy, never getting caught up in the exaggeration of personal recognition and reward.
7. Loyalty: never held myself or the organization hostage for more money by presenting a better opportunity that he may have had elsewhere.
8. Generalist: welcomed many hats and a broad range of responsibilities and accountabilities, never protecting his role as defined by a job description, was always willing to do more.
9. Macro/Micro: capable of high-level strategic thinking as well as flawless, hands-on execution of tactics.
10. Teacher: didn't protect information or use information as power, he taught others his skill sets, tranferring his knowledge to countless people within the organization thereby increasing the organization's bench strength.
|
|
|
ERP Business Process Reengineering |
|
Jun 28, 2008 at 09:23 PM |
|
As a business analyst one important skill set is understanding how to tackle Business Process Reengineering, aiming at improvements by means of elevating efficiency and effectiveness of the processes that exist within and across organizations. It is a fundamental and radical approach by either modifying or eliminating non-value adding activities. The key steps involved in a BPR are: - Defining the purpose and goal of the BPR project;
- Defining the scope of the project so as to include (or exclude) activities; A flowchart of the activities can assist to define the scope of the project;
- Identifying the requirements that will meet the needs of the clients;
- Assessing the environment - the position of competitors, prospective changes in technology, legislation or socio-economic factors;
- Redesigning the business processes and activities in light of the above;
- Implementing the redesigned processes;
- Monitoring the success/failure of the redesign.
Here is an example of an expense process that we implemented in a previous project (all proprietary info have been removed and transformed it into a more generic process) 
|
|
|
|
<< Start < Previous 11 12 13 Next > End >>
|
