| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1408.1 | We allocate everything.... | COOKIE::LENNARD | | Fri Mar 22 1991 12:32 | 25 |
| My work (a software service product manager) is impactly on almost a
daily basis by our lousy admin systems. I "manage" service income and
expenses on 30-40 software products, and have NEVER (in 4 years) seen
a good P&L on any of my products.
My "gut" tells me many of my products have been losing money for years,
but I can't prove it. In answer to one of .0's questions, YES, it is
costing us many times what cleaning up our act would generate....but
I've never seen anyone willing to bite the bullet and spend the
necessary money.
In the good-old-days of high profits we fell into the trap of
allocating everything. I've seen "reports" listing exactly the same
favorable margins on hundreds of software products. And what is even
worse is that the allocation monster works at every level all the way
to the top of the Corporation which is also getting garbage data.
I feel that I should have accurate world-wide software contract and
revenue data that is not over 24 hours old. The Wheaties product
manager for General Mills has that level of info. It is criminal
that we do not.
Sometimes I wonder if we just don't want to know how bad things really
are. Really good data might blow a lot of people out of the water
(and products also).....
|
| 1408.2 | Pandora already in control | CANYON::NEVEU | SWA EIS Consultant | Fri Mar 22 1991 12:59 | 98 |
| Lee,
Who would you like us to bash....
The complexity of our systems is a direct result of the complexity
of Digital. We have asked hundreds of little groups to design and
develop their own solutions that meet their own needs. As these
systems rely on data supplied by other groups and other systems
we asked these folks to work in concert to share their information
and requirements, but we do not tell them to conform to any archi-
tecture or standard procedures.. We have different field layouts
for things as common as part numbers and need bridges and reformat-
ter programs to move data between applications.
OTP has been going on for more than 4 years, but we still have no
idea what needs to be coded when it comes to complex orders. The
reliance on people to enforce unwritten and little understood rules,
is compounded by the complexity of our products. As someone in an
other note commented, a Sales Rep required more than 30 minutes
to look up the 14 plus part numbers required to sell All-in-1
Mail in a large network configuration. The group chartered to
plan, schedule, and develop OTP has been working to define and
implement the requirements of the new admin system, but the pro-
gress is unbelievably slow.
If effort is measured by participation, then tremendous work is
going on. If it is measured by results, well I will let continuing
complaints speak to that issue.
I ask where is the work simplification and continuous improvement
results which should be making systems easier to implement and
eliminate the complexity of doing business. I see more effort
going to justifying cost recovery in each business segment than
going into breaking down the stove pipes which prevent real inno-
vation from occuring.
The system we use are of antiquated design, because noone has
truly captured what the users need from the system, and we have
not figured out how to automate the decisions we leave to humans
to make in the current systems (like scheduling product and
resources). Making order processing real-time, can't happen
unless you eliminate the exception handling and automate the
decision making that is not automated today. We can't let
orders change even after we have shipped them to the customer
as we do today, and expect the system to do all the right
things without developing algorythymns to handle these condi-
tions. We do as much around and outside of the system as we
do inside the system. The decision support that is needed
is not best implemented inside the systems, but rather as
a seperate module which can be called as needed. But this
means that the result of using the decision support needs
to be recorded and transfered into the order management sys-
tem without rekeying etc... We aren't looking at doing it
this way because it might mean having to put PCs, VT1200's,
and/or VAX Stations on everyone's desk. We have a character
cell mentality, we don't understand the power and benefit
of client server design. We need a few simple successes
in applying AI and X-windows technology to our antiquated
systems, then maybe we will begin looking at the problems
with a fresh perspective.
The recent announcement that DEC will be selling a Table Top
PCs from Olivetti and the facetious request that each sales rep
be given one gratus points out just how out of touch our admin
systems really are. There would be significant business justi-
fication for each rep to get a lap top, if the rep could use
it to rapidly develop and enter quotes and orders into the
admin systems. If the rep could use it to access the proposal
system, or use it to check a configuration via X-CON or develop
a layout for a customer via X-Site.
But these monolithic applications require you to be at a terminal
on the immediate network and heaven help you if you are away from
the office more than 50% of the time.
We are telling our Sales, Marketing and Distribution Customers
that the way to design their systems is client/server, to use
the products we have in telemarketing and networking to connect
decision support systems to the order management data, etc...
Meanwhile DEC bets is business on systems we said we needed to
replace five years ago. We agree to disagree on how to proceed
and what to deliver in the next monolithic version of our appli-
cations that support the field. We focus on what helps manage-
ment measure, not what helps sales sell or service organization
to deliver. There are exceptions of course, lots of work has
been done to support proposal writing, but the order processing
call reporting, and people scheduling systems aren't up to the
tasks.
Lee, I hope this note and others help managers re-focus where
we need develop support tools. Maybe we can use some Delta
Ideas to drive process improvements which can be supported by
information systems improvements. Lets not simply change the
information systems and/or the processes to add new things that
have measurement value only. Lets understand why we are changing
and how it will improve the process of selling and delivering
product and services to the customer.
|
| 1408.3 | My opinions - as expressed to Dan Infante | TROPIC::BELDIN | Pull us together, not apart | Fri Mar 22 1991 13:21 | 195 |
| What follows is the text of a memo I sent to Dan Infante (DIM&T VP) on
my ideas about Order Administration.
Outline of an Order Administration System Analysis
1.0 Introduction
I have been observing considerable dissatisfaction with our Order
Administration processes expressed by many people of the company --
Sales and Manufacturing, particularly. I decided that you might be
able to make some use of these observations (and some of my
opinions that are mixed in). This outline is, as they say, FWIW
(for what its worth). You be the judge.
2.0 Problem Statement
Digital's Order Administration Systems are widely perceived as
inadequate for its business requirements.
2.1 There are three while exactly one is required.
Although there are differences among the geographical areas in
which Digital does business, both short and long term
considerations argue against distinct order administration
systems to accommodate the differences. In the short run, we
reinvent many wheels; in the long run, we focus more on our
differences than our unity, proliferating special systems,
discouraging cooperative work, supporting (although
unintentionally) "stovepipes".
2.2 Some key functionality is not addressed.
2.2.1 Ease of use in Sales appears not to have been a priority.
Sales personnel are required to select data codes that do
not represent any sales originated data. This adds
meaningless tasks for persons on the front line of selling
our products, and probably diverts their attention from their
first responsibility, Customer Service.
2.2.2 Support for both rapid and slow information flows does not
appear to be available.
Some products can be produced faster than we can get the
orders from the field to the manufacturing facility. The
comparison is of weeks of order administration to days or
hours of manufacturing cycle time.
Some kinds of information are needed immediately; others
can be delayed without affecting either customer service
or internal operations. It is essential that the
communication requirements be addressed explicitly in the
system design. This does not appear to have happened.
2.2.3 Centralized data management has both costs and benefits
which
must be rationalized.
Decisions about where data management will reside are key
to an effective design. The viability of any system will
depend on its ability to fit the host organization(s) over
its lifetime. Either organizational stability or flexible
support capabilities are required. Technical and
administrative management must agree on this aspect of the
design. The current designs do not seem to have had this
type of management agreement prior to implementation.
3.0 Essential Functional Analysis
This section is limited to the high-level description of essential
functions. These are the only functions which should be addressed
in the initial development. Non-essential functions should be
postponed to subsequent development cycles.
3.1 Required information flows
3.1.1 It must be possible to start with a Product Designator and
retrieve Product Data, including both permanent and variable
data. Each kind of data must also be classified as to what is
needed in real time and what can be delayed.
3.1.2 A Customer Designation should be all that is needed to
retrieve permanent and variable Customer Data. Again, the need
for real time and delayed access must be addressed.
3.1.3 Immediate demand information should be available to a
Supplier almost instantaneously in order to support fast
manufacturing and packaging cycles. Longer term demand can be
provided via slower channels. Obviously, this data must answer
the basic 3 questions, "what is needed", "when is it needed",
and "where is it needed".
3.1.4 Immediate supply information should be available to Sales
immediately, again, future supply information can have a longer
delivery cycle. Again, the basic questions, "what", "when", and
"where" must be answered.
3.1.5 Each financial period should be described as fully as the
financial impact of supply and demand information permits.
There is no business operational need for immediate distribution
of such information, but efficient processing may imply
asynchronous rather than synchronous distribution. Such
financial data must cover both expectations and history.
3.2 Decision points which need carefully defined requirements.
3.2.1 Order Creation represents a major opportunity for
erroneous data to enter the system. There should be
considerable investment made in error prevention and detection.
3.2.2 Credit Approval for customers must be immediate for those
repeat customers without credit holds. Since rapid processing
of the exceptions will speed up revenue generation, there should
be investment in making this process as quick as possible.
3.2.3 Order Approval by technical editors and account management
are opportunities for the process to be delayed. Additional
investment to facilitate each of these areas is justified.
3.2.4 Delivery Promise by the supplier is another opportunity
for revenue delay. Again, investment in this area is justified.
3.2.5 Reschedule of delivery promises, whether initiated by the
customer or supplier should be expedited for near due dates
although more distant promises may be later demands.
3.2.6 Delivery Confirmation by the customer should be an event
which closes a sales episode. Investment should be made to
eliminate delays due to paper management difficulties.
3.2.7 Revenue Recognition should occur only upon delivery
confirmation by the customer. This will help prevent some
game-playing that has been alleged to occur near the end of
fiscal periods.
3.3 Data Management should, in principle, be close to the authority
for defining data.
This will eliminate as many duplicated steps as possible in data
management and will help prevent many transcription errors. Due
to the distributed nature of authority in Digital, data
management should also be distributed. The design should avoid
centralized operations which address the content (as distinct
from the structure, which may be managed successfully from a
central position) of the data.
3.4 Communication requirements are critical in this application.
3.4.1 Real time communication facility
3.4.1.1 Broadcast of data of general interest must be
possible in a mode which attracts nearly immediate attention
of all data users.
3.4.1.2 Directed communication, either real-time or with
short delays, to persons responsible for actions on the
critical path of revenue generation must be possible. At
least confirmation of delivery, and perhaps a confirmation of
reading is required.
3.4.1.3 There is a need for what I call "Searching
Communications", that is, a message is sent out with a
"description of a class of intended recipients", not a
specified distribution list. An example might be, "To
Quality Managers of all manufacturing sites responsible for
products on DEC# xxxxxxx".
3.4.2 Background communication facility
3.4.2.1 Routine transmissions must be handled routinely; that
is, they never fail to occur according to their
specifications.
3.4.2.2 Exceptional transmissions may occur which need either
expedited or delayed communications, with a human or system
launching, but no further attention.
Summary Statement
I hope this outline of some of what I would expect to see in a
document of requirements for a single Digital Order Administration
System (DOAS) is helpful.
yours truly,
Dick
|
| 1408.4 | BNA -> design? nah! just complexity | ANGLIN::BLACK | I always run out of time and space to finish .. | Fri Mar 22 1991 17:04 | 23 |
|
As a sometimes user of SBS (Software Business System - the EIS system
and AIC (centralized reporting system), I can really only commment on
them and what they connect to.
There are really 3 issues: 1) business practices which drive how the
systems are designed 2) conceptual ideas which drive how we get to use
them and 3) the methodology used to determine needs which drives the
design. Many of our business practices are incredibly complex,
inconsistent amongst organizations and meant for our own purposes
(rather than to make it easy for customers to do business with) all of
which need to be BNA-ed in order to drive efficient future design. Our
concept seems to be to have independent applications which require the
user to log into seperate systems to accomplish what are related tasks
- as opposed to being able to stay on one system and just send commands
to other systems. Our methodology of establishing needs seems to ignore
the using community and to concentrate on getting as much complexity
into each sysetm as we can. Because we have so many technical people in
the company, our systems seem to be aimed at them rather than at the
less knowledgeable users - who are often the people who use any given
system the most. I can expound on these topics in detail ... but I
already have and it hasn't gotten me anywhere!
|
| 1408.5 | | RBW::WICKERT | MAA USIS Consultant | Sun Mar 24 1991 17:51 | 25 |
|
Actually, quite a bit of work has been done to integrate Laptops into
the selling process. A pilot was run not too long ago and, while it was
technically a sucess from the integration side, it failed because of the
sheer size of the units and the unwillingness of the sales reps to lug
them around. Now that the notebook units are down in cost and weight
I'm sure it will be revisited.
There is a lot of working being done on client/server models but most
of them have to be shoehorned into existing systems because of
time/cost constraints. The same could be said for non character cell
based interfaces.
There is also a push to get the various development groups "closer" to
their end users. Today much of the system design is done based upon
requirements as defined by a country or corporate headquarters
sales/eis/etc. group vs. the actual end users. This is where quite a
bit of the disconnect comes from since most "headquarters" units are
disconnected from reality anyway...
In many ways I have feel sorry for the people trying to develop admin
systems in Digital. Talk about a moving target!
-Ray
|
| 1408.6 | Let's get our priorities right ! | SHIRE::GOLDBLATT | | Mon Mar 25 1991 02:13 | 15 |
| re.: several
Technology is not the problem to be solved. The main stumbling block
to efficient and effective admin systems is the knowledge of how the
admin processes work, individualy and together. Only when this
knowledge (aka Business Archtecture) is acquired can a plan for
information system support (aka Systems Architecture) be devloped.
It's not only useless but really conterproductive to use new technology
(eg. laptops, 4gl, etc.) as a motivation to change the current set of
systems. The only reason that ought to motivate such change is the
need to support business strategy and tactics.
David Goldblatt - Europe I.M.
|
| 1408.7 | Do unto others | YUPPY::DAVIESA | Phoenix | Mon Mar 25 1991 07:13 | 39 |
|
Re -1
>Technology is not the problem to be solved. The main stumbling block
>to efficient and effective admin systems is the knowledge of how the
>admin processes work, individualy and together
David - I agree with you.
Our admin systems are a total mess.
As a salesperson, I have wrestled with most of them over the years
in an attempt to get data to either support my customers or show
to my management how we are supporting my customers.
They are a nightmare.
HOWEVER....
Many of our customers also have crazy internal systems that have
grown up in just the same manner - bit by bit, over years, from
groups that don't talk to each other. This is "normal".
BUT WE SELL OUR CUSTOMERS CONSULTANCY!
We have some superb skills in Digital for sorting this out - since
we recognised the value of services to our future we have some
even more skilled people that we have brought in....
Why don't we form an internal task force of our own best consultants
and second them for a year to "sell" into Digital in exactly the
same way as they'd sell into a customer?
I.e. discover and state the current position, analyse the problem,
come up with a phased solution and costing for it.
And a small personal theory...
I strongly suspect that one of the reasons that DEC doesn't put
it's salespeople on commission is simply that the admin systems
couldn't handle it. Now, having lousy systems simply results in
salespeople wasting time that they should spend with customers
and a little terseness between admin and sales departments sometimes...
If a rep's *salary* were involved there would be blood spilled...
;-)
'gail
|
| 1408.8 | Is this what you had in mind ? | SHIRE::GOLDBLATT | | Mon Mar 25 1991 08:54 | 235 |
| The following is an extract of the the scope document of the
Digital European Business and Systems Architecture program. This
program was started last September, and is near attainment of its first
main goal ie. the delivery of a draft business architecture for Digital
Europe (excluding the internal operations of Manufacturing and Engineering).
The complete scope document as well as more information about this program
can be obtained from the program manager: Stefan Fazekas @VNO.
----------------------------------------------------------------------------
DIGITAL EUROPEAN BUSINESS- & SYSTEMS-ARCHITECTURE
The purpose of this program is to coordinate all current and future
related activities and to develop ONE Digital Business and Systems
Architecture of the desired future state.
This will cover business functionality plus information requirements
in line with Digital's LRP and major European programs and provide an
architectural framework for systems development activities.
It is a European cross-functional program incorporating the European
architecture activities of all functions except those specific
(ie internal) to Manufacturing and Engineering.
This joint effort will involve major re-structuring of all existing work
done within MP&R, A&L, FINANCE, EIS architectures, UK-Simplification,
GY-Company & Systems Map, OCT-10, FR Master Plan. All relevant contents
and achievements will be incorporated.
II PROGRAM ORGANISATION
II.1 Sponsor: DAVID BARLOW
II.2 Program Manager: Stefan Fazekas
II.3 Program Team: Multi-disciplinary, cross-functional,
cross-geography program team comprised of:
Core Team:
* Field Representatives, as defined by country IM:
France: Michel Bureau
Germany: Sotirios Kougioumtzoglou
Holland: John Derks
Italy: Paolo Nigro
UK: Marie Dugdale
* Area IM:
A&L: Peter Haynes
Customer Services: Ron Brenninkmeijer
Finance: Ray Bach
Systems Business: David Goldblatt
The core team member profile is essentially that of a management
consultant; to define and liase with the sub-groups; coordinate
and drive the activities, but not to own the content.
Sub Teams:
Teams to be set up dependent on definition of major activities
which will be allocated to Field and/or Area and include
Manufacturing.
:
:
* Data Management, Reference, Data Warehouses:
Close liaison to:
. input to, agree and use Subject Area Data Model,
End-point Data Model, and Logical Data Models.
. guide and direct Reference definition (based on
Business processes)
. agree definitions of data warehouses
. exchange learnings and work towards common tools
Data Management: Vasu Briquez
Reference: Valerie Reiss
Data Warehouses: Paul Clifford
II.4 Organisational Interfaces and Responsibilities
Interfaces: Program Sponsor: David Barlow
Area Cross Functional Operations Group:
A&L: Elke Blaha
Customer Services: Frans Reitsma
EIS: Ian Hickson
Finance: Jim Forrest
IM: Christiane Quarterman
Marketing: Al Peters
Selling: Romeo Giussoni
+ DMO: Trevor Greenwood
IM Group:
Area Portfolio Managers
Country IM Managers
Responsibilities:
:
:
Operations Group: To approve the Business Architecture.
Together with respective functional management, to define
Business Priorites.
Together with the IM Group, to agree and approve the
work (re-)allocation, project-teams' scope and
membership. To assign agreed business resources.
IM Group: To approve the Systems Architecture.
Together with the Operations Group, to agree and approve
the work (re-) allocation, project-teams' scope and
membership. To assign agreed IM resources.
To ensure Program remains consistant with IM Mission.
Review body for Program progress and program
recommendations.
Sponsor: To gain support and approval from EMT for this
Program. To liaise directly with functional management as
appropriate. To approve Program Plan, work allocation and
review progress.
III PROGRAM DEFINITION AND JUSTIFICATION
III.1 Problem Statement
We tell our customers that their business world is changing rapidly and
simply planning to do business as usual is no longer valid. We also tell
our customers that correct and innovative use of IT can help to achieve a
competitive advantage.
The above two statements are equally true for us as well as our customers
especially as our market is changing at an ever increasing pace and our
business margins are under enormous pressure. However, we are not
responding to the above and have no clear common vision as to what our
business and systems architecture should be. Instead we have duplicate
analytical work in functions and countries to define the architecture and
duplication of systems development.
This Program is aimed at solving the above problem statement and ensuring
that our current and future systems development support our critical
business processes today and in the future.
David Barlow
III.2 Program Goals
1. A vehicle to help achieve the IM Mission.
2. O N E P R O G R A M
- one approach / one methodology
- field - field - area collaboration
- one source of data for decision making on systems investments
- one tool / work-bench where architectural data are held and
commonly accessible
3. Ensure proper linkage with TA/PA hereunder to maximise Digital's
I.T. opportunities
4. Business-/Systems Models fit "The One Integrated Plan" and other
programs
5. Sell "Digital has done it"
6. Build on what we have already done
7. Eliminate Duplication
III.3 Program Description
DELIVERABLES:
1. Documented Digital Europe Future Business Model
:
:
2. Digital European Systems Strategy
:
:
3. Migration Strategies / Target Systems Architecture
:
:
4. Architecture Implementation
III.4 Critical Success Factors
- Country ownership of assigned responsibility areas and on
behalf of europe.
- Strong top mgmt support and involvement.
- Strong business - organisation - information management link
- Timely availability of appropriate country & area resources.
- Collaboration & clear links between country & area.
- Consistent infra-structure, standards, methods & tools during
program life cycle.
- Availability of business vision, business objectives for each
major business area.
III.5 Usage of deliverables (Perceived Payback and Impact Statement)
:
:
- Decision support basis to assist the design of simplified
business processes, related systems, and consistent simplified
metrics.
- Decision support basis for FY92 investment area's, and FY93
(and beyond) budget planning and allocation.
- Pan-European synchronization.
- Positioning of IT investment project and budgets.
- Integration of IM/IT programs with business and organization
change programs.
- Productivity improvement due to process rationalisation and
work allocation.
|
| 1408.9 | We are what we eat | VAULT::CRAMER | | Mon Mar 25 1991 17:05 | 74 |
| I am a senior technician in the DEC IS Community, working, at present,
in the US Customer Services Order Admin. world.
IMHO replies .5, .6 and .7 speak admirably to the issues. Basically, the state
of the Admin. Systems in DEC accurately reflect the state of the Admin. Bus.
Practices and Procedures in use.
The systems are Byzantine because that's the way the business works. Virtually
every site, be it district, area or region, has their own special way of doing
business. Discounts and allowances vary in size reason and rules according to
the requirements (I'm tempted to say whims) of individual sales folk or managers.
Take as an example the difference between a hardware service product and a
software service product. The former is identified as a code applied to the
hardware model number. On the other hand, every software service offering is
a separate model number of its own with the connection to an actual software
product determined by intelligence built into the model number itself.
I won't even mention the complexity of software licensing!!!
There is a lot of hard work that is going on now that might actually bear some
fruit. The US Admin. functions are being reorganized so that they are all
together, so Services Admin. is no longer separate from sales and product admin.
Also, the IS resources are together to try and focus on those systems in the
most trouble. Believe me, the IS technical community would dearly love to
use the most up to date methods and tools. Unfortunately unless you can start
from scratch it is anything but easy to "phase in" a 2 generation leap in
technology.
The biggest stumbling blocks to improved admin. systems in this company, again
IMHO, are:
1) Distributed authority - .3 mentions many seemingly simple rules for
development of systems. Identifing what data and
functionality is most important is basic. The problem
becomes "Who gets to decide which is which?" I'll
give you a hint, it isn't IS. The rule becomes
he who pays the piper calls the tune. Well, the
money doesn't come from the field, aka the end users.
2) Everyone's an expert - Because of the business DEC is in. Everyone thinks
that they know best how to design and build an
application system, after all we have to know how to
use what we sell, right? This makes it very difficult
for an I.S. professional to act as a professional
Systems Analyst and design a solution to the business
problem. After all for any intelligent person SOLVING
the problem is more fun than merely identifying it.
And if one knows a little about the area.....
Putting 1 & 2 together makes it very difficult for I.S. to attack business
problems. Given the way DEC chooses to DO business on top of that, well,
you see the results every day. Not only is the target moving, but, its motion
is chaotic.
If I could say one thing to people who are frustrated by the poor systems we
have it is this: Scream long and loud to the appropriate people. Get your
requirements into the proper IS organization, and then listen to what they
have to say.
IS is uniquely positioned and has probably a better understanding of the
problems of integrating DECs various business groups than any other single
organization. We do want to be of service, but, we might be able to recognise
a problem with your critically needed enhancement that you might miss.
If we can try and get emotions out of the way and listen to each other, we can
begin to turn DEC into the World Class Service company it ought to be.
Alan Cramer US CSIS Arch. & Advanced Devel.
|
| 1408.10 | Chicken or egg? | YUPPY::DAVIESA | I'm moving into Heffers | Tue Mar 26 1991 06:49 | 25 |
|
RE .8
Yes - that's the sort of thing that I was thinking of.
How encouraging!
An area of concern....
Our internal systems are here to support the way we do business, yes?
(Well, in theory at least, even if they do hinder more than help).
As .10 mentions, our ways of doing business are very messy and
clumsy, and to an extent the systems are likewise because they
mirror the profusion of processes that we have adopted.
I suspect that our "hit squad", in attempting to redesign the
systems, will hit the question "Should be resdesign the working
practices and then make the systems fit those, or should we
leave the practices and design our systems to enable those
practices to run as smoothly as possible?"
The first option sounds like it would take FOREVER - maybe this
is what's happened in the past, and is why we never get to see
any real change in our internal computing resources?
'gail
|
| 1408.11 | egg first, please! | SHIRE::GOLDBLATT | | Tue Mar 26 1991 09:43 | 8 |
| Getting agreement on and publishing the Business Archtecture (BA) is the
first step to process re-designing. The BA is the the common agreement on
the way things work now and the way we would like them to work (ie. "desired
future state"), which permits the design and implementation of the tactics
to get from now to then.
David
|
| 1408.12 | RE: .9 Alan, don't expect the "distribution of authority" problem ... | SEDWS1::COLE | Profitability is never having to say you're sorry! | Tue Mar 26 1991 09:50 | 2 |
| ... to get much better, as of FY92, each ACCOUNT MANAGER
will make their own rules for their accounts.
|
| 1408.13 | We'll be bankrupt, and won't know it!! | COOKIE::LENNARD | | Tue Mar 26 1991 10:37 | 16 |
| In the instance of a significant VMS layered product, and the TOP US
Customer for same, I have been trying since Friday to get an accurate
count of the number and types of licenses this customer has bought, and
what kind of SPS support contract they have. Simple, right? NO WAY.
The financial person cannot cut the licensing data base to that level
of granularity....and U.S. SPS tells me they have no record of them
ever buying a support contract. Meanwhile the customer support center
reports a high level of call activity from this customer but can't
give me any specifics unless I have the customer's access number, which
of course I can't get because they don't appear to have a contract
which of course can't be the case unless the customer really is not
properly licensed which of course can't be the case because.........
I THINK I'M GOING NUTSO! If we had even half-assed admin systems, I
would be able to pull this data, at my desk, in five minutes.
|
| 1408.14 | What is, what isn't, how do we tell the difference? | VAULT::CRAMER | | Tue Mar 26 1991 13:16 | 27 |
| As .12 has pointed out, life for the systems designer is not going to get easier
in the near future. As .13 has pointed out, unless we get our act together we
won't have to worry about it much longer.
As an Admin System designer, I understand the need for flexibility. There is no
great bureaucrat in the sky who can effectivly dictate business practices for
us all ( see also USSR ). BUT, if there is to be a coherent set of Admin.
systems, there is a need to define what the rules are, what the practices are,
and the limits within which flexibility is allowed. For example, every account
manager is NOT free to re-define model numbers. There IS, however, a need to
recognise that customers have their own names for things and we would be wise
to accommodate them (it's called service). As a system designer, I can solve
that problem because I know what the limits are.
Unless there is agreement as to what is and what is not common; we might just
be better off with ( warning heresy to follow ) 4GL stovepipes custom tailored
for the situation; and some brute force converters to role up the disparate
data.
Oh, BTW, one of the problems in answering this is that HQ types have a very
different view of how much flexibility to allow then do the field types.
For 10 pts. guess which group favors more flexibility? (reference .9 and paying
of the piper)
Alan
|
| 1408.15 | Why MIS managers love centralized control | DELNI::B_DONOVAN | Pinin' for the fjords | Tue Mar 26 1991 19:46 | 13 |
| IBM's been claiming for years that you can't build "mission critical"
applications on distributed processors. From reading this topic
(and as a Product Manager who has direct experience with the
shortcomings of our financial reporting and ordering systems), I'd
almost have to agree. The shame of this is that it reflects badly
on our technology when the real culprit is in organizational
stovepiping.
If we can't get our act together, we've got a 3090 in LKG that's got
some spare cycles. ;^)
Bill
|
| 1408.16 | | ESCROW::KILGORE | Wild Bill | Wed Mar 27 1991 07:38 | 18 |
|
Re .15:
> IBM's been claiming for years that you can't build "mission critical"
> applications on distributed processors. From reading this topic
> (and as a Product Manager who has direct experience with the
> shortcomings of our financial reporting and ordering systems), I'd
> almost have to agree.
You'll get a different view on this point from the DECtp group, who's
architecture all but says that the _only_ reasonable approach to "mission
critical" applications is distributed.
Any admin systems people out there who may not be clear on how TP
products can help deliver corporate-wide systems that can be adjusted
to fit local needs, please send mail, or ask questions in the DECintact
conference.
|
| 1408.17 | a case of "sell what you have"? | SAUTER::SAUTER | John Sauter | Wed Mar 27 1991 08:04 | 6 |
| re: .15
Nonsense (IBM's claim, not you). NASA has been developing "mission
critical" applications for years on distributed processors. The Space
Shuttle ones are even provided by IBM.
John Sauter
|
| 1408.18 | It's not the technology... | VAULT::CRAMER | | Wed Mar 27 1991 08:32 | 40 |
| As an Admin. Systems developer / designer for my 11 yrs at DEC, I'll say loud
and clear IT'S NOT THE TECHNOLOGY!!!!!!!
There is nothing wrong with the distributed paradigm IF (and this if is big
enough to eat New York) the organization understands, believes in and supports
that model.
Applications cannot be built for a 6 month market, but, that is exactly what we
have to do. OUR market is the DEC business community and there is a constant
turmoil as to who is in control. The HQ types are consistently trying to
centralize control, while the field orgs. are consistently fighting a geurilla
war to wrest control for themselves.
As an example, I had a senior manager at "Corporate" tell me:
" if they (the field) won't do it our way, I won't send them
the price book".
Heck of an attitude, huh? Now while that is an extreme example, and the
individual doesn't work for DEC anymore, you should get the point.
Example 2; field personnel have deliberately circumvented system controls in
order to "customize" a system data base. You can just imagine what that does
to a roll up; or a system support organization.
Example 3 is much closer to home. I.S. has been balkanized for a long time.
Every business organization of any size has its own IS group. Talk about chaos!
Every IS group thinks it knows best about any standard or design issue, AND,
there is no authority which can say "too bad, do it this way". Since the way
to power and glory is to build up your organization, the rewards come to those
best able to define their unique needs which make it impossible make common
cause with another group. The prototypical problem are YAMS ( yet another
menu system ).
Not to sound like a broken record, this all comes back to "who pays the piper".
Digital is organized in and run with a mindset which makes stovepipes and
systems nightmares inevitable. To make IS work, you either have to change
the organization or change the mindset.
Alan
|
| 1408.19 | Use DECdesign to design a DSS for DEC! | TOOK::DMCLURE | | Wed Mar 27 1991 09:55 | 13 |
| Decision Support Systems (DSS) are actually quite the hot topic
these days in Computer Science/Software Engineering circles. Check
out some of the papers from the Sloane School of Management at MIT
for details. This is likely to become the hot software area for the
nineties.
Anyway, like the development of any *quality* software product,
we need to start by gathering user needs, then translate those needs
into quality requirements. The next step is to then begin to design
the data flow diagrams (DFD). How better to design a software system
for Digital? Why not DECdesign? This product is ideal for such a task!
-davo
|
| 1408.20 | IBM's research people believe differently | MINAR::BISHOP | | Wed Mar 27 1991 10:12 | 11 |
| re: IBM and distributed systems can't be reliable
I have some papers by people at the T. J. Watson center (one of
IBM's research places) on distributed systems. They have code
running on IBM, Sun, Next and HP systems which does reliable
distributed programming.
So IBM may not believe it's impossible to do reliable distributed
systems after all.
-John Bishop
|
| 1408.21 | Dangerous Ideas! | WHOS01::BOWERS | Dave Bowers @WHO | Wed Mar 27 1991 14:20 | 6 |
| re .19;
Please! Such a thorough, structured analysis might reveal things about
our current processes and practices that were better left hidden!
-dave
|
| 1408.22 | | VMSNET::WOODBURY | | Wed Mar 27 1991 15:00 | 7 |
| Re .21:
I detect sarcasm -- you really mean that the powers that be want
to leave hidden.
With the trouble this company is in, I don't think we can really afford
to leave this kind of mess unaired. And it's not at all funny.
|
| 1408.23 | | BUNYIP::QUODLING | Who's the nut in the bag,dad? | Wed Mar 27 1991 16:40 | 27 |
| re references to IBM, this brings to mind 3 Anecdotes...
1. An associate of mine used to be internal DP director for IBM Australia,
One of his first "projects" was to build a system that tracked what happended
with each and every customer. (THis was a 43xx class application). It kep
track of each and every sales call, what was sold, what was proposed, what the
response was, each and every F/S call. Parts consumption etc... It even
followed any cometitive sales people arriving (if they were told about it.)
(IBM were well skilled in this respect... A customer would try to trade off DEC
against IBM, not realizing that everything said was going into competitive
information resources within IBM.) THis person, later work in a Senior
Position at Digital, but has since been transitioned.
2. IN Australia, despite DEC carrying somewhere in the vicinity of $25M worth
of spares locally, there were instances when something had to be P1'd
(Priority 1 order) from the United States. IN discussion with an IBM field
service manager, at one stage, I found that their P1 replenishment was less
than 48 hours. Digital's was running at 10-14 days...
3. IBM and Distributed Processing. I had, at one stage two seperate papers
from the IBM T.J. Watson Centre. One shot "Clustering" down in flames, the
other basically described how IBM would handle a "Cluster" like environment.
The "LOck Manager" was a 4381....
q
|
| 1408.24 | politics and technology | LENO::GRIER | mjg's holistic computing agency | Wed Mar 27 1991 20:56 | 40 |
| I've a lot to say about this topic, because I worked in the IS environment
for too many years in DEC, but I can't say a whole lot because the truth would
(and is!) upsetting to too many highly placed people who could probably still
do bad things to my life and career.
But let's suffice it to say that I see several major problems in the
corporate IS world in DEC. The first is politics. Too many IS managers are
spending more time gathering power and personnell rather than trying to
solve our problems. Attempts to raise awareness of problems and misdesigns
are NOT well received and end up with the individual being black-listed.
Secondly, the technology that the people are using is 1950s at best.
I like to think that the industry and science have advanced somewhat past
the COBOL/flat-file era into a world of structured analysis, design and
engineering. Instead, even brand new systems are being developed as
monolithic pieces of software written using in COBOL, or maybe if you're lucky,
BASIC. Languages don't determine the "goodness" of a system, but they
certainly flavor it, and it's much more difficult to write a large
system utilizing such modern technologies as "modularity" in BASIC or
COBOL than it is in say Ada. (Relatively recently, I won't name names, but
an IS developer was quoted saying that since we're coming out with all these
new fast VAXes, they can stop writing in COBOL and just use DCL! And he wasn't
kidding.)
IS in DEC is still cutting its teeth on relational databases, do you really
think they're ready to use a real TP monitor like ACMS or DECintact?
What we need is to take this high-falutin' consulting we're selling to
customers and telling them how to run their businesses and apply it to
ourselves and use the results. But it'll never happen because then it'll
look like one DEC group trying to exert control over another DEC manager's
private domain, rather than a consultant coming in and giving advice.
I've already probably said too much. The last time I said something
anything like this it stopped my career progress for three years until I
left IS for engineering, hopefully it can't follow me now.
-mjg
|
| 1408.25 | | SAUTER::SAUTER | John Sauter | Thu Mar 28 1991 07:40 | 9 |
| re: .24
A minor nit, COBOL/flat-files were the 60s, not the 50s. The 50s
were EAM (card sorters, etc) and plugboards. You wouldn't have
liked it.
Don't assume that just because you are in Engineering having a negative
attitude won't stop your career progress.
John Sauter
|
| 1408.26 | Simple.....Simpler......Simplistic | VAULT::CRAMER | | Thu Mar 28 1991 09:52 | 56 |
| As I have tried to point out in my previous replies, the problem of Admin.
systems in DEC is NOT one of construction.
There are technicians in IS that avoid the new technology, most of them have been
badly burned by using V1.0 DEC software that couldn't cut it in large scale
applications (See ACMS, Rdb, TDMS, etc.)
DEC IS has a long history of trying to use all the latest products. However,
marketing hype does not always reflect reality. DECdesign, for example,
provides some minor conveniences in exchange for being a resource hog. CDD+
is so slow that compiles take 2 or more times as long. But, none of this is
terribly relevant to the discussion. The problem is not in the tools or the
techniques. Good sytems can be written in RMS and Basic or Cobol and bad ones
can be written with ACMS, Rdb, etc.
The two major problems with Admin. Systems is
1) the way DEC **CHOOSES** to do business
2) the need for systems to exist in the real world of 25 years of stovepipes.
To speak to the 2nd point first, we have been working with the ACMS engineering
group on how phase in ACMS with existing systems. We are pushing the envelope
for DECtp products. There are damn few customers with anything like the size,
complexity AND distributed applications we have to deal with. It is not easy
to phase in a new system when you have to deal with all the "homegrown" network
tools, database managers, screen handlers and the like which IS developed
because THE CONCEPTS OF THE NEW TECHNOLOGY WERE KNOWN TO THE LOWLIEST IS
PROGRAMMER LONG BEFORE THERE WERE ANY PRODUCTS CAPABLE OF DOING THE JOB.
Yet these systems all have to be maintained and integrated with the bleeding
edge of technology. It is simple, and impossible, to develop an entire new
system, from scratch, using the latest and greatest. If engineering wants to
make a BIG hit in the application market they should concentrate on tools that
allow new technology to be retrofitted into existing applications. E.G. ACMS was
unusable for anything but new applications until the systems interface was
developed. DECforms does not integrate well with ACMS except for simple
applications due to the lack of asynch escape procedures. ACMS does not support
variable length passing mechanisms. This, too, presents serious difficulty for
retro-fits.
BUT IT STILL IS NOT A CONSTRUCTION PROBLEM!!!!
This company chooses to do business in a way which makes development of good
admin. systems very difficult. The IS managerial politics mentioned earlier
just mirrored my earlier comments; yes, they are a problem, but, a relatively
small one. The bigger problems are the lack of integration in the various
business groups. The lack of clear authority in business practices; and the
lack of direct linkage between the IS groups and the user groups. This is a
management and organization problem.
Alan
|
| 1408.27 | "Give Me That Old Time Religion" | COOKIE::LENNARD | | Thu Mar 28 1991 17:16 | 11 |
| You'd better hope Distributed Systems are reliable, 'cause we are in
the process of betting the future of this company on our ability
to support them...and I mean REALLY distributed, not just
VMS/ULTRIX/OSF. Can you say NAS.....DCE.....DEC Athena? If these
programs fail, we're in deep doodoo.
I'd love to have 1950's systems to support my business. I'd have a
hell of a lot more data than I have now. Let's see...if I had
everything on Hollerith Cards, a good 029 key punch, an 084 sorter,
and access to a 403 accounting machine.....God, I'd be in heaven.
BTW, I'd dead serious.
|
| 1408.28 | you really want data, not EAM | SAUTER::SAUTER | John Sauter | Fri Mar 29 1991 07:59 | 12 |
| re: .27
Your "old time religion" isn't as old as you think. The IBM 029 was
introduced in the mid-60s. I'm not even sure the 026 was around in
the 50s, you might have to go back to the (non-interpreting) 024 or
even an 010 for the early 50s.
While I agree you'd be in heaven, your lofty position would not be due
to the machines but the data. If you could have all your data on
floppy disk you could be just as well off with a PC as all those
large clunkers.
John Sauter
|
| 1408.29 | sos | NAC::SCHUCHARD | Al Bundy for Gov' | Fri Mar 29 1991 11:38 | 39 |
|
I left IS almost 8 years ago to the day. Nice to see not much has
changed!
Politics involving IS staff's and the businesses they support is almost
always at least 70% of the problem. The competition for resources
from both sides and the ensuing games occupy enormous amounts of time.
You can have tremendous IS people, who know the latest technology,
and get little result due to the management wars.
Digital IS tools typically take up to version 3 before they are useful
enough to process the volumes of data that this company produces.
This seems to be a consistent fact, and speaks much of our engineering
development practices. I recall that the last big IS project i worked
on was to replace the aging MUMPS based Wharehouse systems. When
forced to switch from a vendor based relational system on tops20 to
vms and dbms-32, we naturally went looking for some consulting help
on our vax dbms-32 product. At this time(way back), the consultants
notion of a large database was 1000 records in a parts file. Say
fella, try 150,000... We made it work only to be flushed due to a
series of political issues, one of which was to bring in a new,
universal, manufactoring system, that somehow never really made it
either. See, nothing changes in overhead.
It's really the nature of the process. Overhead functions, and
IS is certainly one, do not have as focused goals as functions which
produce revenue. It is not always clear who is right and who is
wrong and where the priorities lie in the struggle over resources.
When you cannot get businesses to agree over policy and procedures,
very often the underlying cause is resource issues.
I have tons of chaotic stories i could tell from my experience
from 75-83. Seems to me the only thing that has changed, other
than the dec-10's having gone away(they have gone away,right?) is
the chaos has expanded it's borders. From what i see in this note,
the causes are very much the same.
bob
|
| 1408.30 | Anyone have a used PDT-11??? | COOKIE::LENNARD | | Fri Mar 29 1991 12:51 | 13 |
| Re .28.....A P.C.!!! Surely you jest, sir. Don't play with my
feelings. I can't even get rubber bands or slash folders. I agree
I'd love to have one....but are we really sure that they are here
to stay? The industry only sold 33,000,000 last year. Could be just
a flash in the pan.
I would stand a slightly better chance of being selected as the next
Pope than I would of getting any equipment req approved in my organi-
zation. Meanwhile, the engineering group I support has a work station
for every employee, including secretaries. Sigh!!! someday I'd like
to go to work for Digital. Fat Chance.
VT220 Man
|
| 1408.31 | IS systems: threat or menace? ;-) | LABRYS::CONNELLY | arduum cursum angelorum perficere | Sat Mar 30 1991 13:11 | 64 |
|
re: .29
Hey, Bob, you know the scary thing is the last time i checked the SSB
was still using that old MUMPS system we were supposed to replace 10
years ago (for "survival" reasons if i recall). And that failed attempt
to replace it came a few years after a previous attempt had failed! Of
course, i also hear that System T is still clunking along on VMS V4.7!
Maybe what contributed to the lifespan of both of these applications
(for all their numerous technical demerits) was that they were built
very much in accordance with the "Voice of the (internal) Customer".
MUMPS is great for rapid prototyping and throwaway code (now if Bob
Craig can resist jumping on me for that one!), so the client doesn't
have to wait 10 months to see a change request implemented. But that
makes the contrast of the deathly-slow software development cycle with
officially blessed technologies even harder to take for the user. And
with grandfathered applications like the old MUMPS systems, the systems
analysis piece gets massively complicated by the effort to unravel where
all the user's business-specific rules and oddities are hard-coded into
the application AND (by extension) the business process.
I haven't seen any sort of high level explanation from IS/IM&T of how
TA2, TA2+ or whatever else is au courant addresses these issues. The
same problem of Digital software product devlopment times being TOO
SLOW for the external marketplace also applies to internal IS-developed
applications: i'm sure you remember how most of the high level users
who signed off on the functional spec for the warehouse system replacement
were no longer in place by the time coding was well underway...AND the
business conditions were changing too fast (death of FA&T etc.). You
could draw an analogy between MUMPS technology vs. RDB or whatever and
TCP/IP vs. DECnet/OSF. There gets to be a point where you (the user)
just will not wait any longer for architecturally sublime solutions when
a lowly tool exists to get what you want done NOW.
IS is essentially a service bureau. What i see happening with it in
DEC is that:
1. its services are never defined in enough detail for the
timeframes that it can realistically expect to have
a relatively slow-moving target: hence you have mega
amounts of time spent correcting poorly set expectations,
and projects that drag on well beyond the window where
their initial assumptions are still "safe"
2. resources ARE scarce vs. work needed (that doesn't say all
the resources are being productively used), so it's a
must to have strict workload priorities which get
followed up on strictly (or changed via an equally strict
*but simple* process), rather than letting the "PR crisis
of the day" constantly drain resources away from real work
3. maintenance vs. development are too disjoint, too disparately
viewed (in terms of "glamor"), and not realistically
traded off in terms of costs and benefits (else why the
various failed efforts to rewrite and replace what works,
albeit not prettily)
4. IS doesn't have a good abstract model of what its business
is and how it should deploy its resources to satisfy that
business (and it ain't tough to come up with such a model)
--instead it has a lot of "Visions" and 50 ways to say
"we will be the best/flagship/leadership/etc." that verge
on the platitudinous without being super helpful
Is the internal IS business all that different from what EIS is supposed to
be providing to our customers?
paul
|
| 1408.32 | | RANGER::MINOW | The best lack all conviction, while the worst | Mon Apr 01 1991 01:12 | 10 |
| re: .31:
Our customers have all of these problems.
Why aren't we (engineering) developing systems to satisfy them?
Mumps and Datatrieve were both precursors of the PC market's non-programmer
tools. Is this something we've turned away from now?
Martin.
|
| 1408.33 | NADA, NYET, NO | NAC::SCHUCHARD | Al Bundy for Gov' | Mon Apr 01 1991 10:20 | 42 |
|
re: .29 - that's TCP/IP vs DECnet/OSI and you are right on target, as
usual.
The internal/external relationship is the same, with the exception
that the external customer gets to say no, quicker and easier.
Internally, they either go off on their own, ala the old P/L systems
or they get a new IS manager to deal with.
The internal process is clogged by the same types of process for the
customer - too many steps to say NO in. I mean, isn't that the game?
What do I have to do as a client manager to make you say yes? Now,
surely you can remember all the times we both used to pull the clothes
off of various NO's, and how much more efficient we were and happier
the user was when we just did not let them ask the NO person? I mean,
the second worst thing that happens is the NO folks lose function, and the
third worst thing is someone codes a blunder. Of course the first is,
as always, nothing get's done, no sale!
I like your description of useless missions. I can't help it, I always
see, "WE WILL NOT DO ANYTHING BUT WASTE YOUR TIME!!!" whenever I see
one or talk to some manager who mutters one.
The only glitch I ever saw with the old PL systems was their data was
sourced from too many, completely unreliable sources. I always wondered
just how many 11/70's were given away.... However, otherwise they got
what they wanted.
I saw Cat alittle while ago. He said not only system-t but common
scheduling etc were still chugging along. I wonder, is your old
wharehouse code pulling software?
re:.32 - We still don't listen very well. And when we do, too often
is get's corrupted by some program manager or lead technical
persons vision of grandeur. When that happens, you have to shut up,
or find a new job.
SOS - saying no means power for someone. It does not die easily, and
we probably will lay off a good more many people before we change.
bob
|
| 1408.34 | Just say...NO! | VAULT::CRAMER | | Tue Apr 02 1991 13:21 | 21 |
| re: .32 & .33
Just saying NO is the only real power people have in DEC. At the risk of
starting a rodent excavation, management by consensus, which in IS / business
relations is the only acceptable paradigm, gives the power to the negative.
Despite being "empowered" (gosh how I've learned to hate that word!) the only way
I can do the "right thing" is by cajoling all those required for "consensus".
Just one active nay sayer can shoot down the best ideas.
AND, since for every reaction there is .....; active enthusiasm becomes counter-
productive!!! An enthusiastic person will aggravate someone, that one aggravated
individual can now preclude the formation of the necessary consensus.
So, to "do the right thing", you can't encourage enthusiasm you just guard against
active antipathy.
And always remember the golden rule...... He who has the gold, makes the rules.
Alan
|