Delegation
August 9, 2008
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting and have a nice day!
Delegation is an advanced leadership skill. Its one way leaders:
- free themselves of time consuming chores.
- provide followers with development opportunities
- increase the number of tasks accomplished by the work group, team, or committee.
However it is often overlooked and underused in management.
Defined, delegation implies that the leader empowers another person to take responsibility for completing certain tasks or engaging in certain activities. Delegation gives the responsibility for decisions to those individuals most likely to be affected by or to implement the decisions.
Delegation is more concerned with autonomy responsibility and follower development than with participation.
MISUSE OF DELEGATION.
- Failure to delegate authority needed to accomplish delegated tasks.
- Monitoring too closely those delegated to.
- Delegating only those tasks the leaders do not want to do.
IMPORTANCE OF DELEGATION
Frees time for other activities. Leadership entails achieving goals through others. Leaders have to think in terms of the whole group or organizations, capability not just their own. This may cause conflict in some leaders who may have been successful on their own. However leaders have some responsibilities they must delegate. Due to delegation, the leader is able to have some time to attend to those other activities he is more suited or situated to accomplish. Delegation allows the leader to invest his time wisely.
Delegation develops followers. Developing subordinates is one of the most important responsibilities of any leader. Delegating significant tasks to subordinate is one best way to support their growth. This provides the subordinate with opportunities for initiative, problem solving, innovation, administration and decision making. By providing practical experience in a controlled fashion, delegation allows subordinate the best training experience-learning by doing.
Delegation strengthens the organization. Strengthening/developing subordinates strengthens the organization. This depicts that that subordinates are trusted and their development is important. This motivates the subordinates to want to work in the organization. Skillful delegation tends to increase the significance and satisfaction levels of most jobs making subordinate’s jobs better. In turn an organization systematically develops its personnel, its overall experience level, capability and vitality also increases. Delegation therefore stimulates innovation and generates fresh ideas and new approaches throughout the whole organization.
WHY AVOID DELEGATION?
Delegation takes too much time. Delegation saves time for the leaders in the long run, but it costs time for the leader in the short run. It takes time to train the subordinates to perform any new tasks. However when the task is a recurring or repetitive one, the long-term savings will make the additional effort in training worth it, for both the leader and the followers.
Delegation is risky. Delegation is risky i.e. it reduces direct personal control over the work
- The job will not be done as well
- The task is a desirable one
- Others are already too busy.
PRINCIPLES OF EFFECTIVE DELEGATION.
- Decide what to delegate.
- Decide who to delegate
- Make the assignment clear and specific.
- Assign an objective, not a procedure.
- Allow autonomy, but monitor performance
- Give credit, not blame.
POINTS TO COVER WHEN DELEGATING A TASK.
-
How does the task relate to organizational goals
-
When does the subordinate’s responsibility for the task begin?
-
How has the task been accomplished in the past.
-
What problems were encountered with the task in the past?
-
What sources of help are available?
-
What unusual situations might arise in the future?
-
What are the limits of the subordinates authority?
-
How will the leaders monitor the task(e.g. provide feedback)
-
Always convey high confidence and expectations.
INVENTORY MANAGEMENT TECHNIQUES
August 9, 2008
The ABC approach
This is a simple approach where inventory is divided into three or more groups. The rationale is that a small portion of inventory in terms of quantity might represent a large portion in terms of inventory value. For example one group may represent a small percentage of expensive high-tech components while another group may represent a large percentage of relatively inexpensive basic components. In between the two groups there would be a group of components that are of medium value. The first group is referred to as Group A items (small percentage but with a high value). This group is monitored closely and inventory levels are kept relatively low. Group B represents the in between items while group C represents the crucial but inexpensive items that are usually in large quantities, e.g. nuts and bolts.
ECONOMIC ORDER QUANTITY
Economic Order Quantity is that size of the order which gives maximum economy in purchasing any item of material. In order to determine the economic or optimum order quantity, an analysis of the various costs associated with the ordering quantity is made. These costs may be divided into two parts:
a) Material acquisition costs
b) Material carrying costs
Material acquisition costs arise on account of having to process an order. A part of the wages and operating expenses for departments like production control, purchasing, receiving and stores is incurred for purchasing and possessing the materials.
Material carrying costs include interest charges on investment in materials, insurance costs, storage costs etc. These two types of costs behave quite differently.
The material acquisition costs are related to the number of orders placed during a given period. On the other hand, carrying costs, which are variable or semi-variable in nature, tend to change nearly in direct proportion to the level of stock carried in the manufacturing concern.
The formula for economic order quantity is:
Where Co is the cost of placing an order of the stock item
CH is the annual cost of holding one unit of the stock for one year.
D is the annual demand for the stock item
Q is the order quantity
Annual stock holding costs are the average stock quantity multiplied by the annual cost of holding one unit of stock for one year.
INVENTORY TAKING
Inventory or stock taking means the process of determining the value of inventory at any particular date. For this purpose, two methods are adopted:
1. Perpetual Inventory method
This is the recording as they occur, the receipts, issues and the resulting balances of individual items of stock in quantity and value. A simple record called a “bin card” is maintained for each stores item and is updated with receipts into and issues of materials from stores. This method is mostly used with continuous stock-taking system. Recorded balances are compared with physical balances. This method ensures a continual, detailed and reliable check of the stock items and helps the investigation of any discrepancies as they occur.
2. Periodic Inventory method
Under this method, all inventories are counted at one time at regular intervals such as one year or six months. The physical quantities of inventories on hand are ascertained at the end of each year. This may take a few hours or several days depending on each organization. Mostly business is closed for the annual stock taking. The method avoids the continuous stock taking but makes it more difficult to investigate any discrepancies.
INVENTORY VALUATION METHODS (ISSUE PRICING)
The methods that may be used to value material issues from stores are as follows:
1. FIFO (First In, First Out). This method assumes that the earliest units of the stock item received into the stores are the first to be issued out (sold or consumed) and that the stocks remaining in stores are the latest purchases or production. The method is more realistic and gives fair valuation of stock. The main disadvantage of the method is that it does not reflect the current economic values in times of price fluctuations.
2. LIFO (Last In, First Out). This method assumes that the latest (most recent) units of stock item received into the stores are the first ones to be issued out (sold or consumed). The stocks remaining in the sores are assumed to be those which were purchased or produced earliest. The method reflects the current economic value of stocks sold or charged to production but in some cases it is not realistic.
3. Weighted Average Cost (AVCO) method. Under this method, the total value of all items in stock is divided by the number of items in stock and the resultant figure is the weighted average cost price. All issues from stores are then valued at that price until a new consignment of stock units is received into the stores when a new weighted average cost price is calculated. The method is simple and logical but it is not close to current valueofgoods.
Weighted average cost = Total Cost of items in stock / Total Quantity of items in stock
Inventory management
August 9, 2008
Minimum inventory Level
This is that level of an item of material, below which the actual stock should not normally be allowed to fall. It is fixed to ensure that the required quantity of each item of material is available in the stores at all times. To fix the minimum level, the following is taken into account:
- The average rate of consumption of the material
- The time required to obtain fresh supplies
- The reorder level
- The production material requirements
- The minimum quantity of materials which can be procured advantageously.
The minimum stock level is calculated as:
Re-order level – Average expected demand for the stock item during the lead time. This can be stated as:
Re-order level – (Normal consumption x Normal delivery time) where normal delivery time is taken as the average of maximum and minimum time taken for delivery.
Re-order level
This is the stock level fixed between maximum and minimum stock levels, at which an order for the replenishment of stock must be placed. The re-order level is generally higher than the minimum level to cover any emergency which may arise as a result of abnormal usage of materials or unexpected delay in obtaining fresh supplies. To fix this level, the following is taken into account:
- The consumption rate of material
- The margin of safety
- The normal delivery time or lead time
- The minimum level to be maintained
- Cost of storage and interest on capital employed in materials
- Provision for emergencies such as delay in supply and abnormal wastage.
Re-order level is calculated as:
Maximum consumption x maximum delivery time Or
Re-order level = Minimum Stock + Average consumption during normal delivery time. The re-order level is revised frequently considering any factors that are likely to change supply and demand for goods.
Maximum inventory Level
This is the level that should never be exceeded. This is to avoid undue investment of capital leading to a loss of interest, obsolescence of materials, and additional overheads in the form of higher rents, etc. It is determined by taking into consideration the following factors:
- Normal consumption rate of materials
- Time required to obtain new supplies
- Amount of working capital available
- Availability of storage space
- Economic order quantity
- Cost of storage
- Risk of deterioration
- seasonal considerations as to price and availability of material
- Insurance costs
- Other inherent risks associated with the materials and any restrictions that may be imposed by government.
Maximum order level can be determined by using the following formula:
Re-order level + Re-order quantity – (minimum consumption x minimum time for delivery)
Or
Maximum level= Re-order level – Consumption during the time required to get fresh supplies at minimum rate + Economic Order Size.
DANGER LEVEL
Some firms also use the danger level in respect of materials. Danger level is fixed at a point below the minimum level and represents the limit at which special steps must be taken to obtain emergent supplies of material i.e. sending a man personally to bring the required materials. When the stock of a particular item of materials reaches danger level, no further issues are made by the store keeper except on the special requisition approved by the works manager.
Danger Level = Normal consumption per day /per month etc X Time required to obtain emergency supplies.
Average stock level = Minimum Stock level + ½ (Re-order Quantity)
Inventory Control Systems
Red-line method: the simplest, since a red-line is drawn at the lower level inside an inventory bin then inventory is stacked and when the red-line shows, more inventory is ordered.
Two-bin method: Inventory is stacked in two bins. When the working bin is empty, inventory is drawn from the second bin and an order for additional inventory is placed.
Computerized inventory control system: the inventory is computerized and as inventory is withdrawn, they are recorded in the computer and the inventory balance revised. Orders are placed when the reorder point is reached.
Just-In-Time System: it automatically coordinates a manufacturer’s production with suppliers’ production so that raw materials arrive from suppliers just as they are needed in the production process. Also related to Outsourcing.
The Inventory policy must be coordinated with the firm’s manufacturing and procurement policies since the ultimate goal is to minimize total costs and inventory is just one part of the total costs.
Inventory Management
August 9, 2008
Inventory can be classified as supplies, raw materials, work-in-process and finished goods which are essential to a businesses’ operations. Inventory management depends heavily on sales because inventory is purchased earlier than sales can be made and poor inventory levels leads to either lost sales or excessive carrying costs. Any changes in the products’ demand should be worked into the company’s purchasing and manufacturing schedules thus coordination among the sales, purchasing, production and finance departments is important.
The goal of inventory management is to:
- Ensure that the inventories needed to sustain operations are available
- Hold the costs of purchasing and carrying inventories to the lowest possible level
Inventory costs are divided into three categories:
- Carrying costs: are associated with inventory and include cost of capital tied up, storage and handling costs, insurance, depreciation, taxes, losses due to deterioration, obsolescence, or theft. They rise in direct proportion to the average amount of inventory held.
- Ordering costs: include the costs of placing and receiving orders. Are considered to be fixed costs and decline as the number of orders decrease.
- Low inventory costs: results in the loss of sales, customer goodwill and disruption of production schedules.
OBJECTIVES OF INVENTORY CONTROL
- To ensure uninterrupted production. This is essential for smooth flow of production.
- To provide for required quality of materials - to ensure quality production.
- To minimize wastages and losses of materials due to carelessness in storing, issuing and handling.
- To control investment in inventories – to ensure optimum investment of capital in the purchase of materials.
REASONS FOR HOLDING INVENTORY
Stocks are held to increase sales and profits. When stock is held, production can continue uninterrupted to meet customer demands. However, holding stock can be expensive. The objective of a stock policy should be to minimize the total annual costs associated with stock. The total costs associated with stocks include:
- Purchase costs
- Holding stock
- Ordering stock
- Stock-outs (the costs of being without stock when it is needed).
Holding costs include interest on capital, the costs of storage space and equipment, administration costs and losses from deterioration, pilferage and obsolescence.. These costs can be minimized by keeping stock levels to a minimum.
Order costs are incurred every time stock is purchased from a supplier. Order costs include the buyer’s time spent contacting the supplier, and the storekeeper’s time spent checking the goods received. These costs can be reduced by placing orders only at infrequent intervals. But this would mean that the order quantities would have to be large to avoid stock-outs between the orders and this would increase holding costs. To minimize order costs and holding costs, businesses purchase materials in their economic order quantity (EOQ). The EOQ is the purchase order quantity that minimizes total order costs plus stockholding costs.
Stock-outs also incur costs. Customers might go elsewhere if the goods they require are out of stock. Similarly, production will be disrupted when there is no material to use. Buffer stock is a basic level of stock held for emergencies to cover unexpected demand for the stock item.
Business Process reengineering BPR
August 5, 2008
BPR is a form of organizational improvement. It aims to improve a business through restructuring of processes. BPR is given force by the thinking that old ways of organizing work are no longer appropriate for a competitive business environment. The ultimate aim of re-engineering processes to achieve better quality, service and innovativeness. The radical restructuring entailed in BPR is risky and uncertain.
Theoretical Foundations of BPR:
For hundreds of years, commercial activity has been based on the Adam Smith principle of Division of Labor. Division of labor encourages specialization and thereby leads to improved productivity.
The classical enterprise also exhibits the concepts of:
- Hierarchical control:- the classical layers of management
- Mass production of largely uniform goods/services
An organization based on these principles is successful in a stable market environment, characterized by growing demand for uniform goods/services. In a changed market environment characterized by sever competition, globalization, more demanding customers, smaller profit margins etc, the classical organizational models are less and less appropriate. BPR provides one alternative to the old methods of organizing business processes. The goals of BPR can be started in expanded form as either cost objectives or service objectives.
Cost Objectives:
- Reducing stocks: New materials or Intermediate goods
- Economies of scale in procurement
- Reduced staff costs (administrative costs)
- Competitive pricing of goods/services
Service Objectives:
- More reliable delivery system
- Stock availability
- Good after sales service
- Quick Response/adaptation to market changes
- Reduced product development lifecycle
Qualities of Re-engineered Processes:
- Several jobs are combined into one. This implies a reversal of the Adam Smith principle of division of labor and function. Workers make decisions, actual work and decision making are integrated.
- Processes are reorganized so that tasks are done in the most sensible/logical order.
- Checks and controls are reduced. The checks and controls are reduced to the minimum acceptable level. The checks and controls are also deferred.
- Reconciliation is minimized.
- A case manager is appointed to oversee the re-engineering process.
- Hybrid processes that combine centralization and decentralization by use of communication technology are often adopted.
- Processes have multiple versions (polymorphic) – the process is re-designed to include capabilities to deal with custom orders.
Contribution/Role of IT in BPR:
- IT is all essential enable of BPR; it enables processes to be re-engineered.
- It supports the re-engineered process
- Leading edge technology products can be particularly useful in process innovation. They can even lead the innovation process.
- IT also facilitates process integration.
- It has been argued that the most effective contribution of IT in business redesign is to enable an enterprise to do things that it was not doing before – extending the capabilities of the enterprise.
Candidates for BPR:
In theory, any business process can be subject to BPR; but in practice, certain processes can benefit more from BPR than others. Such processes have the following qualities
Dysfunction: The process is visibly out of order, it is problematic. Dysfunction in a process occurs when the process is slow (frustratingly slow), occasional complaints, generates errors etc.
Importance: Important processes that have a prominent place in the value chain. They contribute directly to the delivery of goods and services to the end consumer.
Feasible: From the managers stand point the BPR project is technically, economically and socially feasible/viable. Processes that require high capital input, or enjoy limited management support are less feasible for BPR.
What causes BPR projects to fail? (Pitfalls in BPR):
- Inadequate funding
- Insufficient management commitment/support
- Poor project leaders
- Inadequate feasibility evaluation
- Resistance to process change
- Failure to focus on most process re-design and dwelling on improving the existing process.
- Quitting too early or declaring victory too soon.
Re-engineering computer system:
At a minimum a computer system comprises of an ordered collection of hardware, software, and data resources. Computer systems are the basis for automated information system.
- Re-engineering computer systems means examining, rethinking and re-implementing such systems in a new form.
- The process is usually carried out on legacy options, re-implementing them in a more modern form.
- Re-engineering computer systems can be seen as a management response to the challenge of keeping old systems alive within a changing environment.
Merits
- The useful life of a system is increased
- The business value of such a system also increases
- Future maintenance costs are reduced
- The morale of maintenance staff may improve; because they know they are working in a modern system i.e. the systems become more maintainable.
Steps for BPR
- Identify process for innovations
- Manage business
- Manage people and work
- Identify change levels ( technology etc)
- Develop process vision – what you want to process must fit with the strategic direction of the organization (IS)
- Understand existing processes – study current process and understand necessary changes
- Design and prototype new process/create design of new process.
Approaches to re-engineering computer systems:
When a system is re-engineered any of the following changes may occur:
- It may be placed in a distributed platform.
- It will usually be re-documented
- The data may be migrated to a new database platform
- The code may be restricted
- The code may be written in a different language
Automatic Source Code Conversion:
This entails the use of software tools to convert source code in a given language.
- to code in a newer version e.g Cobol 74’ to Cobol 90’
- to code in a different language e.g Cobol 74’ to Oracle
The software tools cannot achieve 100% conversion and hence has to be supplemented with manual conversion.
Automated Program Restructuring
When code is maintained over an extended period, its structure and hence its efficiency, deteriorate. Indeed, the more a software product has been maintained, the more it costs to maintain it in future. When the program is re-structured:
- irreconcilable code is detected and removed
- complex control structures are simplified
- program modularity is enhanced
Use of software tools may not be fully effective. Manual rewriting of code may still be applied.
Automated program and Data Restructuring:
When the existing data structures are re-structured then even the programs that process the data have to be reviewed. When data is restructured:
- The overall model may be re-organized into one database.
- Data in a relational model may be modified to suit the needs of a different relational DBMS.
Re-engineering or Re-developing?
Systems targeted for re-engineering have 2 qualities
- They are heavily/regularly used
- They are currently being maintained a lot
Re-engineering usually has two main merits over re-developing. These are:
- Lower costs: re-engineering costs about ¼ of redeveloping
- Reduced risk: lower likelihood of making mistakes.
When deciding whether to re-engineer or to redevelop you may consider such issues as:
- budget provisions or costs constraints
- current state of the old system; the old system may be so old and messy that it may not be susceptible to re-engineering
- Time limitations: re-engineering is likely to be quicker than to redevelop
- Scope i.e. system scope; if the scope of the existing system is to be excluded substantially then it may be more practical to redesign and re-implement the system instead of re-engineering it.
- Perceived risk level; Risk arises from the combined effect of many factors. If the perceived project risk is high then it might be safer to re-engineer the system than to redevelop it.
Link between reengineering of computer systems and BPR:
Computer systems are usually embodied within business processes/systems such as accounts receivable, production planning, marketing and distribution, human resources etc. When such process/systems are re-engineered, then the supporting technology infrastructure also needs to be reviewed.
The overall aim of reengineering a computer system should be to re-align it with the existing business goals. The goals of a BPR project require an altered IT infrastructure then the existing infrastructure should be reengineered or re-developed.
System development methodology
August 4, 2008
“A methodology” is a recommended collection of philosophies, procedures, rules, techniques, phases, tools, documentation, management and training for developers of IS.
Objectives of Methodology
-
To capture, record and document accurately, the user needs.
-
To monitor the project and report on progress (project management ability)
-
To facilitate the development of quality system within the set time and set budget
-
To facilitate proper documentation of both project process and the project deliverables, assisting in future maintenance.
-
To facilitate at an early stage the mechanics of change control.
-
To facilitate the delivery of system that are liked by the end user.
-
Complete coverage of all the development activities involved in system development.
-
Simplicity: The tools, techniques e.t.c. should be easy to use.
-
Validation of the designs:- the methodology should conclude a mechanism for reviewing its own results.
-
Separation of analysis from design, there should be distinct focus on user need, quite separate from implementation needs.
A methodology can be said to have various features. These features can be categorized into technical model and managerial model.
A methodology needs to have a technical model. This model includes features like the tools, tools which will help the developers in the process of developing an Information System. These tools help in every phase or sub phase involved in the methodology. e.g. CASE tools, project management tools, Drawing tools , Data dictionary e.t.c.
A methodology also needs to have a technique. A methodology can have many techniques, Techniques helps to verify and expound on the methodology, thus they enable the phase and subphase of methodology to be carried out according to the methodology’s principle.
Technique act as guides of methodology’s phase. Technique address different parts (phases) of a methodology.
Techniques also enable easy understanding of what the methodology requires e.g. root pictures, conceptual model, DFD, Decision trees/tables, Entity Life Cycle, Structured diagrams, normalization e.t.c.
A methodology also needs to have a philosophy, in that it needs to have the underlying theories and assumptions that the authors of the methodology believes in. This feature helps to shape and guide the development of an Information System. It also enable the understanding of the methodology.
A methodology also has a managerial model that has a feature of a methodology. This feature is that of the development structure, in that a methodology needs to have a development structure that;
-
Identifies the phases, subphases, steps and tasks to be done in the methodology.
-
Identifies the outputs to be produced and under which circumstances they should be produced.
-
Constraints to be applied and people to be involved. This feature provides for the development process to be really managed and controlled.
Initially in the early 60s there was no appreciation for a methodology. Application systems were developed without the aid of an explicit Information System development methodology.
Also there was a growing appreciation of analysis and design parts of the system development and therefore the role there was increased demand for the role of an analyst and programmer.
There was also a realization that as organization grow in size and complexity. It was desirable to move away from one-off solution to a more integrated Information System.
There was also appreciation of an accepted methodology for the development of an I.S.
What is the rationale for writing a methodology
The rationale for writing a methodology are:
The methodology should improve the end product of a development process i.e. a better I.S.
A better development process: In that the methodology should provide improved management and project control so that the organization can gain from the benefits that accrue from a tightly controlled development process.
Selecting/Adopting
Theoretically speaking, the best methodology is the one that is best suited to the project work at hand. In practice, the best methodology may be the one that the designer understands well.
In some cases, the right methodology is the one that has been recommended within the organization’s standards.
Common Approaches
Adhoc: No formal recognition is given to methodologies
Contingency Approach: We use different methodologies, depending on the nature of the project.
Prototyping / Evolutionary Development: We use it in those context where the user needs are unclear, the business area is unfamiliar, the level of risk is high e.t.c.
Adavantages of a methodology
-
Increased user involvement translating to a more likeable system.
-
Prototyping has the inherent capacity for accommodating risks.
-
Quicker systems Development.
-
Superior User Interface.
-
Missing functions/features can be detected early.
Disadvantages of a methodology
-
Poor documentation.
-
Confusion between the prototype and the real system.
-
Project Management is difficult.
-
It is difficult to draw up a prototype contract.
-
As a consequence of poor documentation system maintenance may be difficult.
PRINCE (Projects IN Controlled Environments)
August 4, 2008
This project command structure may perhaps not be widely applied but it brings out the nature of the roles we tend to encounter in most systems development projects.
Steering Committee
This committee may go under different titles, but its main role is to guide expenditure on Information systems (IS) with a view to ensuring that such expenditure is in line with the business goals. It is the steering committee’s responsibility to ensure that projects concentrate on solving the business problem. Such a committee may undertake the following duties:
-
Formulating the IS strategy/plan
-
Prioritization of projects
-
Setting terms of reference for individual projects
-
Project progress control
-
Quality and acceptance testing
-
Project funding
Project executive/Sponsor
-
Taking care of project funding and organizing for the release of funds that have been allocated to the project.
-
Project progress control, perhaps in conjunction with the steering committee if one exists.
-
Justification of the project to the management body in charge.
-
Specifying the minimum requirements that the projects must meet if it is to achieve its business objectives.
-
Provide high level support as a champion for the projects
-
Keeping the project board or higher management informed of progress.
Senior User
-
Assisting in system requirements definition
-
Assisting the project team with quality review of the system interfaces.
-
Voicing the concerns of the perceived implications of a proposed system.
Project Manager/Leader
-
Supervision and motivation of the project team
-
Allocation of duties
-
Progress control on a day to day basis
-
Reporting on project progress to the project sponsor or senior management
-
Recommend termination of the project to the sponsor if necessary
-
Select and manage sub-contractors
Quality Control
This role may be served by a quality control team, quality control supervisor or some other person.
-
Setting the quality standards
-
Suggesting quality review techniques
-
Undertaking the quality review and making the appropriate recommendations
Technical roles
Depending on the project any or all of the following technical roles may be applied:
-
Business/System Analyst
-
Application programmers
-
System programmers
-
Analyst programmers
-
Telecoms engineers
-
Designers
-
Network technicians
-
Secretarial support staff
-
Data entry personnel
Analyst/programmer role
This role has become prevalent in the last 15 years and is the result of a number of forces/pressures. An analyst programmer is in charge of both system analysis and programming.
Some of the factors contributing to the increased popularity of this role are as follows:
-
A desire to reduce communication problems in system development: in the classical approach an analyst prepares a specification which a programmer subsequently applies a program coding, there is always a chance of communication breakdown between the two parties.
-
With the increased use of IT, even small enterprises are investing in the area however the system development workloads tend to be small and more attention is devoted to maintenance of existing system. It is therefore viable to have a limited number of personnel who can carry out both system analysis and programming.
-
Desire for increased productivity/efficiency: When a programmer implements a design specification that he wrote himself he may be able to do so quickly because no time is wasted in trying to understand the specification. The system is therefore implemented sooner.
-
Changes in a system development approaches, with the increased use of object oriented system development, it appears reasonable that the analysis and programming work is carried out by one person or the same group of people.
NB: This role appear to be quite popular even with the large organization indicating that the arrangement may be working well.
A person designated as a programmer analyst is likely to acquire a broader range of skills on the job with a positive effect on his career progression. However when mistakes are done there is less opportunity for detecting and correcting them. It is also likely there will be reduced rigor in problem analysis with adverse effect on overall system quality.
Object oriented technology
August 4, 2008
Emergence of Object Technology
This is essentially a software (as opposed to hardware) technology. It may be seen to be a programming design, database design or just a system development methodology. This technology is generally seen to represent a new and different system development paradigm/framework
In a way, the emergence of object oriented databases technology represents an effort to address the limitation of the popular relational model.
As a programming paradigm object oriented programming represents an attempt to radically improve on the existing structured programming practices. This technology is an entity that encapsulates both state and behaviour i.e. data, methods and processes.
Under this technology, systems are developed by or through modeling objects i.e. defining the objects, defining their states and behaviour, their interactions, classifications e.t.c.
The technology uses specialized environments; programming languages and database systems with object oriented support.
Advantages of the object technology
-
High potential for reuse i.e. objects are reusable components. This may be beneficial in that systems can be constructed quickly and cheaply.
-
Reduced maintenance load because well defined objects tend to be stable than conventional code and data tables.
-
object oriented databases tend to support higher quality data. Constraints can be more rigorous. This approach produces normalized models.
-
object oriented databases provide better performances, quicker access to data.
-
Ability to model/design advance databases systems, modeling of sounds, images in addition to text, modeling of complex inter-relatioships e.g CAD, CASE, multimedia systems e.t.c.
Why is the technology not so widely applied:
-
There is a time lag between the development of any new technology and its widespread use. People take time to adopt.
-
Object modeling seems to be conceptually more complex than its predecessors.
-
Their credit affect people who have the prerequisite skills and knowledge to steer the organization transition to this technology.
-
There is a lot of investment currently on relational DBMS and the cost of transition to object oriented will be very high
-
The relevant model is capable of handling most of the basic /conventional data processing need, thus most organisations are still benefiting from the current DBMS and thus the pressure to move to object technology is therefore minimized
-
Current database system have limited support for object technology which might be adequate for some business application.
Data Warehouse
August 4, 2008
Data Warehousing
Data warehousing represents an attempt to turn coporate data into a source of knowledge. A data warehouse has the principal aim of providing information that is truly useful for strategic decisions making. Information that constitutes a summarized and objective view of all areas of the enterprise.
A Data warehouse is a corporate decision support resource. It is a database that brings together data from diverse sources making it serve tactical/strategic decision needs.
One definition cites a warehouse as a support oriented, integrated, time variant and non-volatile collection of data in support of mangement’s decision making process.
Definition Quality of a Data Warehouse
Subject Oriented: i.e. data is organized along the lines of the key business entities e.g. suppliers, customers, stock e.t.c.
Integrated: the Data is from different subjects, sources and applications. It is held in such a way that it can all be applied collectively as one source
Qualities of Data
-
Time Variant; the data pertains to both current and past operations. The data occurs in layers parameterized by time.
-
Non-Volatile: the data is kept for a prolonged period of time without being changed or destroyed. However old data is stored in a more summarized form.
-
Specifically supports top level decision making.
-
Transaction levels are relatively low.
-
Applied at random intervals in a non-deterministic way.
Structure /Components of a Data Warehouse
-
Sources of operational Data
-
-
Old manufacture databases systems (corporate db systems)
Departmental Data (in databases or old filing systems)
External sources e.g. commercial data firms, internet etc
-
-
-
Load Manager (Front end component): this captures and prepares data, placing it in the data warehouses.
-
Warehouse Manager: This tool manages the data inside the data warehouse i.e. it does refining, back up e.t.c.
-
Query Manager (Back end component): Receives queries, schedules them and directs them to the correct data tables.
-
End user access tools: Used by the end user to place queries or otherwise process the data in a data ware house e.g. querry /reporting tools, data mining tools, online analytical processing tools.
-
Current data i.e. Data in the warehouse that pertains to recent operations. This is usually detailed data.
-
Summarized data: Data that pertains to past operations, retained in lightly or highly summarized form.
-
Archive data: old data images of the warehouse retained fort archive purposes.
Advantages of Data Warehousing
-
Very useful for trend analysis (assessing progress)
-
Improved quality of senior management decisions: good decisions often translate into better strategic advantage.
-
Great potential for competitive advantage in that analysis of the data warehouse may reveal patterns or trends that were previously unknown thus managers can capitalize on this information for competitive posturing.
-
High returns on investment
-
Improved managerial control because the manager has a broader and deeper weight into all areas of the enterprise which enables them to control the enterprise more effectively.
Disadvantages of Data Warehousing
-
Projects have a long time frame: the longer a project takes the more risky it becomes.
-
Some of the required data may be missing from operational systems; the data gaps presents a design challenge.
-
Other problems in the operational systems: if there is a problem with the system or operational system this problem may be transferred to the warehouse.
-
Data warehouse systems are high maintenance systems.
-
Underestimation of the data loading needs.
-
Need for large storage facilities: storage needs may be in the order of multiple petabytes.
-
Increased end user demands: When the warehouse is installed user requests for assistance and /or information may increase instead of reducing.
-
Data ownership; the data in the warehouse is a trully shared resource thus lack of data ownership.
-
Data homogenization: The data in the warehouse may infact not serve the intended purpose.
Data Marts
This is a small-scale data warehouse, specifically intended for departmental/divisional use.
The data mart may be a logical unit of the corporate data warehouse or it may be an independent resource.
The emergence of Data marts is a response to the challenges associated with the design and operation of enterprise wide data warehouses.
A Data mart is smaller and thus easier, cheaper and quicker to develop.
A data mart enables us to enjoy the benefits of a data warehouse, but on a smaller scale.


