Accounting Case Analysis: Electronic Commerce Network (A) & (B)

158-C01B 4/23/01

Professor William Lawler, Babson College, prepared this case as a basis for class discussion rather than to illustrate either effective or ineffective handling of an administrative situation.

Copyright © by William Lawler 2001 and licensed for publication at Babson College to the Babson College Case Development Center. To order copies or request permission to reproduce materials, call (781) 239-6181 or write Case Development Center, Olin Hall, Babson College, Wellesley, MA 02457. No part of this publication may be reproduced, stored in a retrieval system, used in a spreadsheet, or transmitted in any form or by any means – electronic, mechanical, photocopying, recording, or otherwise – without the permission of copyright holders.

Electronic Commerce Network (B) Dave Roger was excited by the initial work of the activity analysis group. Now that the

Customer Capture and Customer Loading processes and their underlying activities and associated costs were more transparent, people that controlled these activities could begin to understand the underlying cost structure. Clearly, if even a "good" customer cost over $150,000 to capture and load onto ECN.W's network, a large number of transactions would have to be processed before ECN.W could even recoup these costs. Dave was also excited about the number of initiatives that had been started to move ECN.W towards the ideal cost for these two processes. Connecting activities to underlying costs did lead to process improvement -- the virtuous cycle that he had so often read about. But now he was interested in "knowing" what it cost to process a transaction since this was the key. His business plan forecasted "a customer willingness to pay" factor of between ten and fifteen cents per transaction. If he knew this transaction processing cost, he could forecast customer profitability and convince investors of the long-run viability of his business in this next investment round.

Denise Pizzi's group found this process to be much more complex than the first two. So far they had assembled a large amount of data.

o Cost Pool -- The transaction processing system at ECN.W had three front-end N/T systems that did the order entry, credit processing and fulfillment inventory management. They sat on a UNIX backbone system that also ran the database. Analysis of the general ledger accounts found that these costs fell into two groupings – people and system depreciation. The transaction-processing group had nine people -- one systems manager/technician and eight technicians that provided service on a 24-by-7-by-365 basis. At any given time, two technicians were on hand. One monitored the system and troubleshot any transaction-related problems while the other handled all hardware-related problems. Ideally, the group would have liked to cost the N/T systems independently of the UNIX backbone. However, they did not have that fine a separation of costs in this area and ultimately grouped all of them together. Since the UNIX system represented the large majority of the cost, the group thought this caused no material error. In total, at the current capacity level, the systems cost about $1.35 million a year in depreciation of hardware and amortization of software. ECN.W was writing off the technology over a three-year life, which was deemed reasonable.

ECN.W (B) 158-C01B

o Driver -- The driver for this cost pool was clearly the number of transactions processed,

but arriving at the proper measure was difficult. ECN.W was handling about 20,000 transactions per day on average or about 7.3 million per year (20,000 x 365). Initially, the group divided this total into the cost to run the system – people and systems, to estimate the cost for each transaction that was processed.

o Transaction variability -- Since the IT system required for ECN.W’s transaction

processing was not easily scalable, the initial choice of hardware had been based on future demand. Thus, they had chosen a system capable of processing 120,000 transactions a day even though they were only processing 80,000 transactions per day at peak demand. Similarly, ECN.W managers had decided to staff to handle total system capability.

Exhibit 1 Transaction Processing Volume

Time

Average per day 20,000 transactions/day

Peak demand per day 80,000 transactions/day

System capacity 120,000 transactions/day

2