費用コードに対する事前課金Charging Ahead on Charge Codes

この記事は、「Trenches」のコレクションに含まれています。This article is part of our "From the Trenches" collection. プロジェクト管理システムまたはタイムシートシステムの組織の費用コード構造を定義するためのベストプラクティスについて説明します。It describes best practices for defining your organization's charge code structure for the project management system or timesheet system.

この記事の Word バージョンをダウンロードするには、「 課金コードでの課金」を参照してください。To download the Word version of this article, see Charging Ahead on Charge Codes.

その他の記事については、 ホワイトペーパー「Trenches」を参照してください。To see more articles, see "From the Trenches" white papers.

費用コードに対する事前課金Charging Ahead on Charge Codes

多くの場合、組織が自分のプロジェクト管理システムまたは自分のタイムシートシステム用に料金コード構造を定義するのを支援するよう求められています。I'm often asked to help organizations define their charge code structure, either for their project management system or their timesheet system. すべての組織が異なるため、さまざまな料金が発生する場合がありますが、お客様にとって一般的な共通のプラクティスがいくつかあります。While it's true that every organization is different and different needs result in different types of charges, there are some common practices we've found over the years that are universal.

その他については以下を参照してください。Ask less, not more

Bureaucracy はありません。したがって、費用のコード構造が複雑になるほど、ユーザーが正確なレポートを作成する可能性が低くなります。No one likes bureaucracy, so the more complex a charge code structure you make, the less likely it will be that people make accurate reports. たとえば、長いフラットリストに1万料金コードのリストを作成して、その中から選択するとします。Imagine, for example, that I make a list of 10,000 charge codes in a long flat list to choose from. この特定のタイムシートまたはプロジェクトの更新について適切な選択肢を見つける前に、ドロップダウンリスト内の各項目を調べて、1時間ずつスクロールしなければならない場合があります。You might have to scroll for an hour, examining each possible entry in a drop-down list before you'd find the exact right choice for this particular timesheet or project update. その後で、リストの残りの部分をスクロールして、もう少し正確でないものが見つからないかどうかを確認する必要があります。Then you'd need to scroll through the rest of the list to make sure you didn't find something that wasn't just a little more exact.

ばかげたことはありません。Let's not be silly. そのような操作はありません。No one will do that. すぐに終了したように見える最初のエントリを取得し、それを選択します。They'll take the first entry that seems reasonably close and choose that. それができない場合、最終的には、すべての時間が請求金額 "999: その他" になります。Failing that, all hours will ultimately end up in charge "999:Miscellaneous".

そのため、簡単にリストを作成できます。So make your list simple. 理想的には、スクロールする必要はありませんが、1つの画面に表示するか、または1つのクリックで表示する必要があります。Ideally, it should not require scrolling at all, but should be visible on a single screen or perhaps with one more click. つまり、最大で20-30 のオプションから選択することだけが可能です。That means that you're only choosing from 20-30 possible options at most. この場合、より少ない方になります。In this case, less is more.

管理がさらに詳細になると判断された場合は、より正確で精度を向上させる方がよいことを説明します。If management is determined to get much more detail, remind them that it is better to get more accuracy and less detail than more detail and less accuracy.

既にわかっていることを確認しないDon't ask what you know already

各部署または各プロジェクトに同一の手数料コードがある、さまざまな費用コード構造を確認しました。I've seen many charge code structures where there is an identical charge code for each department or each project. また、ユーザーが既にプロジェクトを選択するように求められていて、たとえば会議のためのエントリを行っている場合は、その行アイテムが "このプロジェクトの会議" になっていることを知っているので、このようにすると、pollute が複数の会議アイテムで費用リストを扱うことができます。Yet, if people are already being asked to choose the project and we're doing an entry for meetings for example, then I know that the line item must be "meetings on this project" so why pollute the charge list with multiple meeting items? 同じロジックが部署と一緒に保持されます。The same logic holds with departments. 各部署に属する従業員の一覧がある場合は、それらの部署が既にわかっています。If we have a list of employees who belong to each department, then we already know what department they're in. Pollute の請求金額一覧は、「販売部門の会議」、「技術部門の会議」、および「マーケティング部門の会議」と共に表示されます。Why pollute the charge list with "Sales department meeting", "Technical department meeting" and, "Marketing department meeting". "会議" と呼ばれる1つのアイテムを作成し、従業員の部署と、会議の対象となっているプロジェクトを推定することができます。Just make one item called "Meeting" and we can deduce from the employee's department and the project they're on what the meeting was for.

解決策を改善するために解決するBe resolved to better resolution

プロジェクトとタイムシートの適切な解決レベルを選択することは、一般的な課題です。Picking an appropriate level of resolution for your project and your timesheet is a common challenge. 管理する必要のあるレベルについては、次の条件を考慮してください。 1) データを収集するときよりも、データの価値を高める必要があります。その日のすべてのレポートを使用する場合は、どのような作業を行いますか。Think about what level you want to manage things in with these conditions: 1) There needs to be more value in the data than in the time to collect it, so if you spend all day reporting on your day, how will you actually get anything done? 2) 決定するための準備が整ったレベルで作業します。2) Work at a level that you're prepared to make decisions on. 3) より複雑なデータを入力すると、正確なデータを取得する可能性が低くなります。3) The more complex it is to enter, the less likely you are to get accurate data. 4) 可能であれば、すべてのユーザーが同じ解決レベルで作業するようにして、期間が10分のタスクで1つのグループを管理しないようにします。4) When possible, get everyone working at the same level of resolution so you're not managing one group in tasks that are 10 minutes long and another in tasks that are 3 days long. 多くのユーザーにとって、特定の日について3-5 行の詳細を報告できることは、十分に詳細です。For many people, being able report 3-5 lines of detail for a given day is plenty of detail.

データの条件Condition your data

ユーザーによっては、エンドユーザーが同じ質問に答えることがあります。Some people will make the end user answer the same questions over and over. たとえば、"R d" の列が含まれているシステムが表示されました & 。これは、この金額が R d の税クレジットの請求対象ではないことを意味 & します。For example, we've seen systems with a column for "R&D" meaning that this charge is or is not a charge eligible for an R&D tax credit. しかし、各ユーザーのタイムシートの各行ではなく、タスク自体に適格性を関連付けることができる必要があります。But we should be able to associate the eligibility to the task itself rather than each line of each person's timesheet. さらに、一部のユーザーが資格を満たしていると考えられる場合にはどうすればよいでしょうか。Moreover, what would I do if some users thought that it was eligible and some users thought that it wasn't? このようなシナリオの例としては、「Design-R d 用の設計」 & および「設計-対象外の r d」などの例も & あります。This likely scenario also plays out in examples such as, "Design-eligible for R&D" and "Design-not-eligible for R&D". これにより、金額コードの数は、戻り値がないことが倍になります。This doubles the number of charge codes for no return in value. R & D のフラグごとに対象として値をドロップダウンしている場合は、各ユーザーに対して各週に表示されるようにエンドユーザーに質問する必要はありません。Just have someone in R&D flag each drop down value as eligible or not and you won't have to keep asking end users to try to figure it out each week.


プロジェクトおよびタイムシートシステムの向上により、データの階層的な表示が可能になります。Better project and timesheet systems allow a hierarchical display of data. 選択肢がありませんが、多くの選択肢がある場合は、階層を構築することによって、多くのデータをより簡単に swallow することができます。If you have no choice but to have a lot of possible choices, then building a hierarchy can make a lot of data easier to swallow. 各レベルで選択できるように、最大で5-10 のアイテムを選んでください。Think of 5-10 items at maximum to choose from at each level. さらに多くのレベルを作成したくありません。And don't be tempted to make dozens of levels. 3-4 レベルの階層を作成して、ほとんどのオプションをカバーできるようにする必要があります。Making a 3-4 level hierarchy should be able to cover most options. 4レベルのシステムでは、レベルごとに10個のアイテムがあります。1万の料金が発生する可能性があります。After all, 10 items per level in a 4-level system is 10,000 possible charges. プロジェクトはより複雑ですか?Is your project more complex than that?

少ない表示Show me less

ユーザーに与える質問や選択肢が少ないほど、より良いものになります。The fewer questions and choices you give your users, the better off you'll be. バックグラウンドで応答できるものがある場合は、タイムシートでユーザーに質問しないようにしてください。If there is anything you can answer in the background then try not to ask it of users on your timesheet. 目標は、可能な限り多くのデータを収集することではなく、可能な限り正確な画像を収集することです。また、エンドユーザーがデータ、質問、およびオプションに影響を与えることがないようにした場合に、より良い方法を選択できます。The goal is not to collect the most data possible, it's to collect as accurate a picture as possible, and you'll do better at that if you insulate the end users from data, questions, and options that make no difference to them.

そのデータに対して何を行いますか。What will you do with that data?

中間管理の種類では、提案されているものよりも「より詳細」が必要であるということがよくあります。「これで何が行われるのか」ということです。I'm often told by middle-management types that they need "much more detail" than I'm suggesting and my response is always the same: "What will you do with it?" タスクベースのタイムシートデータを収集する目的は、より優れたビジネス上の意思決定を行うことにあります。そのため、多くの場合、これらの中央のマネージャーは、より詳細な情報を持っていたとしても、よりよいと考えられるビジネス上の意思決定をすることになります。The purpose of gathering task-based timesheet data is to make better business decisions, so I'll often ask those middle managers what business decision they're not able to make now that they think they'd do better at if they had more detail. 何らかの方法で情報を確認し始めると、それほど多くは必要でないことがわかります。When you start to look at information that way, you find that you probably need less of it. 会議に費やした時間の合計だけでなく、送信中のタスクやオーバーヘッドのタスクでは、これらのタスクがどれだけ発生しているかを調べるのに十分な場合があります。It might be enough to find out just the total number of hours spent in meetings or in transit or in overhead tasks than to find out what every one of those tasks was.

詳細を掘り下げます。Drill deeper… 必要な場合のみbut only when you must

タイムシート分析の実行を開始して、時間のすべてが発生している場所を把握すると、特定の結果を見つけることができます。When you start to do timesheet analysis to figure out where your hours are all going, you are bound to find some disproportionate results. Defy 期待値に比べて非常に大きな時間がかかる場合は、少し掘り下げてください。Where you find an unusually high percentage of hours that defy expectation, drill a little deeper. しかし、それほど深くはありません。But not too deep. その料金について、さらに詳細な層を追加して、取得するデータを表示します。Add one more layer of detail for that charge and give it a few weeks to see what data you get. 考えられるのは、発生する可能性のあるすべての種類の会議について、「ミーティング」などの1つのチャージコードを50の新しい料金コードに拡張することです。The temptation will be to expand a single charge code like "meetings" into 50 new charge codes with every possible type of meeting that could occur. このことを考慮して、代わりに1つの充電コードを5または6に変更してください。Try resisting this temptation and instead change that 1 charge code into 5 or 6. 詳細情報を取得していない場合や、まだ結果が得られない場合は、少し掘り下げてください。If you don't get the detail or you still have disproportionate results, delve a little deeper.

クリーンな住宅を維持するKeep a clean house

チャージリストのサイズは増加する傾向がありますが、減らないことがあります。Charge lists have a tendency to increase in size but never decrease. そのような場合は、それらを定期的に見直し、膨張を排除することをお勧めします。It's a good practice to review them on a regular basis and eliminate bloat. その場合は、さらに正確な情報が得られる可能性が高くなり、時間が失われている領域を特定できるようになります。If you do, you're more likely to continue to get more accurate information and be able to identify areas where you're losing time.


費用コード管理: プロジェクトスケジュールまたはタイムシートシステムのどちらを使用するかに関係なく、効率的なシステムと、非常に多くの定義があり、十分な精度を持たないシステムとの違いを実現できます。Charge code management—whether it is for your project schedule or your timesheet system—can make the difference between an efficient system from which data can be counted on or a system with too much definition and not enough accuracy. 費用コード構造を設計する場合は、少なくとも、より少ない数で始めることをお勧めします。When you design your charge code structure, we recommend starting with less, not more. 必要に応じて後で詳細を追加する方がはるかに簡単です。これは、詳細を取り消して、圧倒されたユーザーにとって簡単にすることです。It's much easier to add more detail later if it is required than it is to undo more detail and make it simpler for overwhelmed users.

著者についてAbout the Author

Chris Vandersluis 氏は、Microsoft 認定パートナーである、カナダベースの HMS ソフトウェアである Montreal、創設者の社長およびです。Chris Vandersluis is the president and founder of Montreal, Canada-based HMS Software, a Microsoft Certified Partner. McGill 大学と30年以上のプロジェクト管理システムの自動化において、経済の学位が得られています。He has an economics degree from McGill University and over 30 years experience in the automation of project control systems. プロジェクト管理協会 (PMI) の長期のメンバーであり、Microsoft Project ユーザーグループ (MPUG) の Montreal、トロント、およびケベックの章を見つけました。He is a long-standing member of the Project Management Institute (PMI) and helped found the Montreal, Toronto, and Quebec chapters of the Microsoft Project Users Group (MPUG). Chris が執筆した刊行物には、フォーチュン、ヘビー建設ニュース、コンピューティングカナダ雑誌、PMI の PMNetwork などが含まれており、彼はプロジェクトの時間の正規の columnist です。Publications for which Chris has written include Fortune, Heavy Construction News, Computing Canada magazine, and PMI's PMNetwork, and he is a regular columnist for Project Times. McGill 大学の高度なプロジェクト管理を指導しており、北アメリカと世界各地のプロジェクト管理関連機能で講演していることがよくあります。He teaches Advanced Project Management at McGill University and often speaks at project management association functions across North America and around the world. HMS Software は、TimeControl のプロジェクト指向の timekeeping システムの発行者であり、1995以降の Microsoft Project Solution Partner になっています。HMS Software is the publisher of the TimeControl project-oriented timekeeping system and has been a Microsoft Project Solution Partner since 1995.

Chris Vandersluis 氏は、次の場所に電子メールで連絡することができます。 chris.vandersluis@hms.caChris Vandersluis can be contacted by e-mail at: chris.vandersluis@hms.ca

Chris Vandersluis 氏がより多くの EPM 関連記事を読む場合は、「HMS の EPM ガイダンスサイト (」を参照してください https://www.epmguidance.com/?page_id=39) 。If you would like to read more EPM-related articles by Chris Vandersluis, see HMS's EPM Guidance site (https://www.epmguidance.com/?page_id=39).